Which GCC? I built sparse on Ubuntu with 4.8 and -fpic - still nothing. This must be Fedora specific somehow. Regards, Vitaly > On 14 Jun 2014, at 11:44 pm, Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > > On Fri, 13 Jun 2014 08:56:50 -0700 > Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote: > >>> On Fri, Jun 13, 2014 at 08:05:37AM -0400, Jeff Layton wrote: >>> On Thu, 12 Jun 2014 18:06:25 +1000 >>> Vitaly Osipov <vitaly.osipov@xxxxxxxxx> wrote: >>> >>>> Nothing shows up for me on x86_64, allmodconfig, linux-next from 10 of >>>> June. My sparse has been compiled from sources. >>>> >>>> $ make fs/locks.o C=2 CHECK="/home/vosipov/bin/sparse" >>>> CHK include/config/kernel.release >>>> CHK include/generated/uapi/linux/version.h >>>> CHK include/generated/utsrelease.h >>>> CALL scripts/checksyscalls.sh >>>> CHECK scripts/mod/empty.c >>>> CHECK fs/locks.c >>>> >>>> $ sparse —version >>>> v0.5.0 >>>> >>>> $ which sparse >>>> /home/vosipov/bin/sparse >>>> >>>> Regards, >>>> Vitaly >>>> >>>> >>>>> On Wed, Jun 11, 2014 at 11:51 PM, Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: >>>>> On Wed, 11 Jun 2014 16:11:46 +0300 >>>>> Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: >>>>> >>>>>>> On Wed, Jun 11, 2014 at 07:06:32AM -0400, Jeff Layton wrote: >>>>>>> $ rpm -q sparse >>>>>>> sparse-0.5.0-1.fc20.x86_64 >>>>>>> >>>>>>> I see it all over the tree, but an easy example is fs/locks.c: >>>>>>> >>>>>>> $ make fs/locks.o C=1 >>>>>>> make[1]: Nothing to be done for `all'. >>>>>>> make[1]: Nothing to be done for `relocs'. >>>>>>> CHK include/config/kernel.release >>>>>>> CHK include/generated/uapi/linux/version.h >>>>>>> CHK include/generated/utsrelease.h >>>>>>> CALL scripts/checksyscalls.sh >>>>>>> CHECK fs/locks.c >>>>>>> include/linux/err.h:35:16: warning: dereference of noderef expression >>>>>>> include/linux/err.h:30:23: warning: dereference of noderef expression >>>>>>> include/linux/err.h:35:16: warning: dereference of noderef expression >>>>>>> include/linux/err.h:30:23: warning: dereference of noderef expression >>>>>>> CC fs/locks.o >>>>>>> >>>>>>> It has two IS_ERR calls and two PTR_ERR calls, and each generates the >>>>>>> warning. >>>>>> >>>>>> I downloaded the Fedora SRPM and built the binary but I still wasn't >>>>>> able to reproduce the bug. >>>>>> >>>>>> dcarpenter@speke:~/progs/kernel/devel$ /tmp/sparse/sparse-0.5.0/sparse --version >>>>>> 0.5.0 >>>>>> dcarpenter@speke:~/progs/kernel/devel$ make C=2 CHECK=/tmp/sparse/sparse-0.5.0/sparse fs/locks.o >>>>>> CHK include/config/kernel.release >>>>>> CHK include/generated/uapi/linux/version.h >>>>>> CHK include/generated/utsrelease.h >>>>>> CALL scripts/checksyscalls.sh >>>>>> <stdin>:1226:2: warning: #warning syscall finit_module not implemented [-Wcpp] >>>>>> <stdin>:1229:2: warning: #warning syscall sched_setattr not implemented [-Wcpp] >>>>>> <stdin>:1232:2: warning: #warning syscall sched_getattr not implemented [-Wcpp] >>>>>> <stdin>:1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp] >>>>>> CHECK scripts/mod/empty.c >>>>>> CHECK fs/locks.c >>>>>> dcarpenter@speke:~/progs/kernel/devel$ >>>>>> >>>>>> I'm on today's linux-next. I can't think of a kernel configuration >>>>>> issue which would cause this... >>>>>> >>>>>> regards, >>>>>> dan carpenter >>>>> >>>>> Could it be arch-specific then? What arch are you using? I'm on x86_64. >>>>> I know that quite a few other people have mentioned seeing these >>>>> warnings as well, so I'm pretty sure it's not just me. >>> >>> Ha! It turns out that my hand-built sparse also works fine, so the >>> problem seems to be in the Fedora package. >>> >>> With a little trial-and-error, I figured out what's causing the >>> problem, but I'm a little baffled as to why it's occurring. >>> >>> The Fedora SRPM builds the program with -fpic. When I remove that flag, >>> this problem goes away. I'd appreciate any insight into why that would >>> break things. I doubt PIC really makes much difference security-wise in >>> sparse, so removing it shouldn't matter much, but I wonder if this >>> indicates an underlying bug in sparse itself? >> >> Wow, that's horrifying. I wonder if it might indicate a miscompilation >> by GCC. Does the problem persist if you build with -fpic -g? If so, >> you could set a few breakpoints and try to determine at what point the >> behavior of the two sparse binaries diverges. > > Yeah, this is a bit disturbing. Fedora already builds with -g, so yes, > the problem does persist. I made a very small, simple C file that just > calls IS_ERR to test with. > > Broken sparse (built with -fpic): > > Breakpoint 1, expand_dereference (expr=0x7ffff6f12210) at expand.c:629 > 629 if (expr->ctype->ctype.modifiers & MOD_NODEREF) > (gdb) p expr->ctype->ctype.modifiers > $3 = 0x65686374616d6e75 > > Built w/o -fpic at the same breakpoint: > > Breakpoint 1, expand_dereference (expr=0x7ffff5e61bd0) at expand.c:629 > 629 if (expr->ctype->ctype.modifiers & MOD_NODEREF) > (gdb) p expr->ctype->ctype.modifiers > $2 = 0x0 > > The stack at that point is: > > (gdb) bt > #0 expand_dereference (expr=0x7ffff5e61bd0) at expand.c:629 > #1 expand_preop (expr=0x7ffff5e61bd0) at expand.c:736 > #2 expand_expression (expr=expr@entry=0x7ffff5e61bd0) at expand.c:984 > #3 0x000000000041217a in expand_cast (expr=0x7ffff5e61c50) at expand.c:777 > #4 expand_expression (expr=expr@entry=0x7ffff5e61c50) at expand.c:992 > #5 0x00000000004123e2 in expand_compare (expr=0x7ffff5e61cd0) at expand.c:514 > #6 expand_expression (expr=<optimized out>) at expand.c:978 > #7 0x00000000004127ba in expand_preop (expr=0x7ffff5e61d10) at expand.c:752 > #8 expand_expression (expr=<optimized out>) at expand.c:984 > #9 0x00000000004127ba in expand_preop (expr=0x7ffff5e61d50) at expand.c:752 > #10 expand_expression (expr=<optimized out>) at expand.c:984 > #11 0x0000000000412364 in expand_arguments (head=0x7ffff5e39810) at expand.c:767 > #12 expand_call (expr=0x7ffff5e61b90) at expand.c:832 > #13 expand_expression (expr=expr@entry=0x7ffff5e61b90) at expand.c:995 > #14 0x000000000041217a in expand_cast (expr=0x7ffff5e61e10) at expand.c:777 > #15 expand_expression (expr=<optimized out>) at expand.c:992 > #16 0x0000000000411c75 in expand_statement (stmt=stmt@entry=0x7ffff5fe3920) at expand.c:1202 > #17 0x0000000000411e13 in expand_compound (stmt=0x7ffff5fe38d0) at expand.c:1133 > #18 expand_statement (stmt=stmt@entry=0x7ffff5fe38d0) at expand.c:1164 > #19 0x00000000004124ec in expand_expression (expr=<optimized out>) at expand.c:1007 > #20 0x0000000000411dad in expand_statement (stmt=stmt@entry=0x7ffff5fe3880) at expand.c:1161 > #21 0x0000000000411e13 in expand_compound (stmt=0x7ffff5fe3830) at expand.c:1133 > #22 expand_statement (stmt=0x7ffff5fe3830) at expand.c:1164 > #23 0x0000000000411c21 in expand_symbol (sym=sym@entry=0x7ffff5e312d0) at expand.c:1068 > #24 0x0000000000401675 in check_symbols (list=0x7ffff6a63610) at sparse.c:281 > #25 0x0000000000401208 in main (argc=<optimized out>, argv=<optimized out>) at sparse.c:300 > > ...so something is corrupting the modifiers field at least and maybe > the whole ctype itself? I don't know the sparse code that well, so I'll > need to do some more digging to determine the root cause. > > -- > Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
