Em Wed, Aug 13, 2014 at 09:03:49PM +0400, Alexey Brodkin escreveu: > >From "include/uapi/asm-generic/statfs.h" it is seen that "statfs.f_type" is > >of > type "__statfs_word" which in its turn is "__u32" (unsigned int) for 32-bit > systems. > > So in case of compilation with "-Werror" following breakage happens: > --->--- > fs.c: In function ‘fs__valid_mount’: > fs.c:76:24: error: comparison between signed and unsigned integer expressions > [-Werror=sign-compare] > else if (st_fs.f_type != magic) > ^ > cc1: all warnings being treated as errors > --->--- > > Note that now when fs.c is in "lib/api/fs" and in "tools/lib/api/Makefile" > CFLAGS has hard-coded "-Werror" this is inevitable even if one builds "perf" > with "WERROR=0".
So we have one more case of comparision involving f_type: [acme@zoo linux]$ find tools/ -type f | xargs grep -w f_type tools/lib/api/fs/fs.c: else if (st_fs.f_type != magic) tools/lib/api/fs/debugfs.c: else if (st_fs.f_type != (long) DEBUGFS_MAGIC) [acme@zoo linux]$ Do we have to apply the same fix to that other case as well? Interestingly it does it on a different way, that by your description above would make it fail on 32-bit systems, no? - Arnaldo > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com> > > Cc: Vineet Gupta <vgu...@synopsys.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Jiri Olsa <jo...@kernel.org> > Cc: Cody P Schafer <d...@codyps.com> > Cc: Arnaldo Carvalho de Melo <a...@redhat.com> > --- > tools/lib/api/fs/fs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c > index c1b49c3..4b2fa7b 100644 > --- a/tools/lib/api/fs/fs.c > +++ b/tools/lib/api/fs/fs.c > @@ -75,7 +75,7 @@ static int fs__valid_mount(const char *fs, long magic) > > if (statfs(fs, &st_fs) < 0) > return -ENOENT; > - else if (st_fs.f_type != magic) > + else if ((long)st_fs.f_type != magic) > return -ENOENT; > > return 0; > -- > 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
