Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression

[Jeff Layton <jlayton@poochiereds.net>]

On Fri, 13 Jun 2014 08:56:50 -0700
Josh Triplett <josh@joshtriplett.org> 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@gmail.com> 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@poochiereds.net> wrote:
> > > > On Wed, 11 Jun 2014 16:11:46 +0300
> > > > Dan Carpenter <dan.carpenter@oracle.com> 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@poochiereds.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html