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

Commit Message

Jeff Layton June 10, 2014, 9:38 p.m. UTC

From: Jeff Layton <[e-mail]>

Lately, when I do a make with C=1, I get *tons* of these warnings:

    include/linux/err.h:35:16: warning: dereference of noderef expression
    include/linux/err.h:30:23: warning: dereference of noderef expression

...so many that it's really driven down the signal to noise ratio. I've
taken a look at what's driving these warnings and I really just don't
get it. The pointers being passed in aren't being dereferenced as far
as I can tell, so what is sparse complaining about?

Even odder, just in playing around I've noticed that removing the
__force directives seems to silence these warnings. This is really
strange since all of the docs I see indicate that __force is supposed to
help silence sparse warnings, not cause them.

This patch just removes the __force directives on the err.h inlines and
that silences the warnings for me. Dan originally added those in commit
e7152b97f38f1 (err.h: IS_ERR() can accept __user pointers).

I don't really consider this a serious proposal for inclusion, but
rather just a starting point for discussion. What's the right way to fix
this problem? Is this a bug in sparse?

Signed-off-by: Jeff Layton <[e-mail]>
---
 include/linux/err.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

Comments

Dan Carpenter June 11, 2014, 5:45 a.m. UTC | #1

On Tue, Jun 10, 2014 at 05:38:49PM -0400, Jeff Layton wrote:
> From: Jeff Layton <[e-mail]>
> 
> Lately, when I do a make with C=1, I get *tons* of these warnings:
> 
>     include/linux/err.h:35:16: warning: dereference of noderef expression
>     include/linux/err.h:30:23: warning: dereference of noderef expression

Which version of Sparse, which version of the kernel and which .c file
can I compile to reproduce this?

I built fs/cifs/ and I didn't see the sparse warning.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jeff Layton June 11, 2014, 11:06 a.m. UTC | #2

On Wed, 11 Jun 2014 08:45:18 +0300
Dan Carpenter <[e-mail]> wrote:

> On Tue, Jun 10, 2014 at 05:38:49PM -0400, Jeff Layton wrote:
> > From: Jeff Layton <[e-mail]>
> > 
> > Lately, when I do a make with C=1, I get *tons* of these warnings:
> > 
> >     include/linux/err.h:35:16: warning: dereference of noderef expression
> >     include/linux/err.h:30:23: warning: dereference of noderef expression
> 
> Which version of Sparse, which version of the kernel and which .c file
> can I compile to reproduce this?
> 
> I built fs/cifs/ and I didn't see the sparse warning.
> 
> regards,
> dan carpenter
> 

$ 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.

Dan Carpenter June 11, 2014, 1:11 p.m. UTC | #3

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
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jeff Layton June 11, 2014, 1:51 p.m. UTC | #4

On Wed, 11 Jun 2014 16:11:46 +0300
Dan Carpenter <[e-mail]> 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.

Vitaly Osipov June 12, 2014, 8:06 a.m. UTC | #5

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 <[e-mail]> wrote:
> On Wed, 11 Jun 2014 16:11:46 +0300
> Dan Carpenter <[e-mail]> 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.
>
> --
> Jeff Layton <[e-mail]>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jeff Layton June 13, 2014, 12:05 p.m. UTC | #6

On Thu, 12 Jun 2014 18:06:25 +1000
Vitaly Osipov <[e-mail]> 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 <[e-mail]> wrote:
> > On Wed, 11 Jun 2014 16:11:46 +0300
> > Dan Carpenter <[e-mail]> 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?

I'll do a bit more investigation, but I should be able to get a fixed
package pushed into Fedora soon. Thanks for the help, and obviously the
RFC patch I originally "proposed" can be dropped.

Josh Triplett June 13, 2014, 3:56 p.m. UTC | #7

On Fri, Jun 13, 2014 at 08:05:37AM -0400, Jeff Layton wrote:
> On Thu, 12 Jun 2014 18:06:25 +1000
> Vitaly Osipov <[e-mail]> 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 <[e-mail]> wrote:
> > > On Wed, 11 Jun 2014 16:11:46 +0300
> > > Dan Carpenter <[e-mail]> 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.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jeff Layton June 14, 2014, 1:44 p.m. UTC | #8

On Fri, 13 Jun 2014 08:56:50 -0700
Josh Triplett <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
> > > > On Wed, 11 Jun 2014 16:11:46 +0300
> > > > Dan Carpenter <[e-mail]> 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.

Vitaly Osipov June 14, 2014, 2:05 p.m. UTC | #9

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

Jeff Layton June 14, 2014, 4:47 p.m. UTC | #10

On Sun, 15 Jun 2014 00:05:22 +1000
Vitaly Osipov <[e-mail]> wrote:

> Which GCC? I built sparse on Ubuntu with 4.8 and -fpic - still nothing. This must be Fedora specific somehow. 
> 
> 
> Regards,
> 
> Vitaly 
> 

$ gcc --version
gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7)

Yeah, playing around a little more, it seems like -fpic alone is not
enough to trigger it, but CFLAGS='-O2 -fpic' seems to cause it. Can you
confirm whether that helps you to reproduce it as well? Also, I'm on
x86_64 (in case the arch matters here).


> > On 14 Jun 2014, at 11:44 pm, Jeff Layton <[e-mail]> wrote:
> > 
> > On Fri, 13 Jun 2014 08:56:50 -0700
> > Josh Triplett <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
> >>>>> On Wed, 11 Jun 2014 16:11:46 +0300
> >>>>> Dan Carpenter <[e-mail]> 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 <[e-mail]>

Patch

diff --git a/include/linux/err.h b/include/linux/err.h
index a729120644d5..284897f403b3 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -25,17 +25,17 @@  static inline void * __must_check ERR_PTR(long error)
 	return (void *) error;
 }
 
-static inline long __must_check PTR_ERR(__force const void *ptr)
+static inline long __must_check PTR_ERR(const void *ptr)
 {
 	return (long) ptr;
 }
 
-static inline bool __must_check IS_ERR(__force const void *ptr)
+static inline bool __must_check IS_ERR(const void *ptr)
 {
 	return IS_ERR_VALUE((unsigned long)ptr);
 }
 
-static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
+static inline bool __must_check IS_ERR_OR_NULL(const void *ptr)
 {
 	return !ptr || IS_ERR_VALUE((unsigned long)ptr);
 }
@@ -47,13 +47,13 @@  static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
  * Explicitly cast an error-valued pointer to another pointer type in such a
  * way as to make it clear that's what's going on.
  */
-static inline void * __must_check ERR_CAST(__force const void *ptr)
+static inline void * __must_check ERR_CAST(const void *ptr)
 {
 	/* cast away the const */
 	return (void *) ptr;
 }
 
-static inline int __must_check PTR_ERR_OR_ZERO(__force const void *ptr)
+static inline int __must_check PTR_ERR_OR_ZERO(const void *ptr)
 {
 	if (IS_ERR(ptr))
 		return PTR_ERR(ptr);