* [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
@ 2014-06-10 21:38 Jeff Layton
2014-06-11 5:45 ` Dan Carpenter
0 siblings, 1 reply; 11+ messages in thread
From: Jeff Layton @ 2014-06-10 21:38 UTC (permalink / raw)
To: linux-kernel; +Cc: dan.carpenter, linux-sparse, Jeff Layton
From: Jeff Layton <jlayton@primarydata.com>
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 <jlayton@primarydata.com>
---
include/linux/err.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
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);
--
1.9.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-10 21:38 [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression Jeff Layton
@ 2014-06-11 5:45 ` Dan Carpenter
2014-06-11 11:06 ` Jeff Layton
0 siblings, 1 reply; 11+ messages in thread
From: Dan Carpenter @ 2014-06-11 5:45 UTC (permalink / raw)
To: Jeff Layton; +Cc: linux-kernel, linux-sparse, Jeff Layton
On Tue, Jun 10, 2014 at 05:38:49PM -0400, Jeff Layton wrote:
> From: Jeff Layton <jlayton@primarydata.com>
>
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-11 5:45 ` Dan Carpenter
@ 2014-06-11 11:06 ` Jeff Layton
2014-06-11 13:11 ` Dan Carpenter
0 siblings, 1 reply; 11+ messages in thread
From: Jeff Layton @ 2014-06-11 11:06 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-kernel, linux-sparse, Jeff Layton
On Wed, 11 Jun 2014 08:45:18 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> On Tue, Jun 10, 2014 at 05:38:49PM -0400, Jeff Layton wrote:
> > From: Jeff Layton <jlayton@primarydata.com>
> >
> > 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.
--
Jeff Layton <jlayton@poochiereds.net>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-11 11:06 ` Jeff Layton
@ 2014-06-11 13:11 ` Dan Carpenter
2014-06-11 13:51 ` Jeff Layton
0 siblings, 1 reply; 11+ messages in thread
From: Dan Carpenter @ 2014-06-11 13:11 UTC (permalink / raw)
To: Jeff Layton; +Cc: linux-kernel, linux-sparse, Jeff Layton
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-11 13:11 ` Dan Carpenter
@ 2014-06-11 13:51 ` Jeff Layton
2014-06-12 8:06 ` Vitaly Osipov
0 siblings, 1 reply; 11+ messages in thread
From: Jeff Layton @ 2014-06-11 13:51 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-kernel, linux-sparse, Jeff Layton
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.
--
Jeff Layton <jlayton@poochiereds.net>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-11 13:51 ` Jeff Layton
@ 2014-06-12 8:06 ` Vitaly Osipov
2014-06-13 12:05 ` Jeff Layton
0 siblings, 1 reply; 11+ messages in thread
From: Vitaly Osipov @ 2014-06-12 8:06 UTC (permalink / raw)
To: Jeff Layton; +Cc: Dan Carpenter, linux-sparse, Jeff Layton
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.
>
> --
> 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
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-12 8:06 ` Vitaly Osipov
@ 2014-06-13 12:05 ` Jeff Layton
2014-06-13 15:56 ` Josh Triplett
0 siblings, 1 reply; 11+ messages in thread
From: Jeff Layton @ 2014-06-13 12:05 UTC (permalink / raw)
To: Vitaly Osipov; +Cc: Dan Carpenter, linux-sparse, Jeff Layton
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?
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.
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-13 12:05 ` Jeff Layton
@ 2014-06-13 15:56 ` Josh Triplett
2014-06-14 13:44 ` Jeff Layton
0 siblings, 1 reply; 11+ messages in thread
From: Josh Triplett @ 2014-06-13 15:56 UTC (permalink / raw)
To: Jeff Layton; +Cc: Vitaly Osipov, Dan Carpenter, linux-sparse, Jeff Layton
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.
- Josh Triplett
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-13 15:56 ` Josh Triplett
@ 2014-06-14 13:44 ` Jeff Layton
2014-06-14 14:05 ` Vitaly Osipov
0 siblings, 1 reply; 11+ messages in thread
From: Jeff Layton @ 2014-06-14 13:44 UTC (permalink / raw)
To: Josh Triplett; +Cc: Vitaly Osipov, Dan Carpenter, linux-sparse, Jeff Layton
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-14 13:44 ` Jeff Layton
@ 2014-06-14 14:05 ` Vitaly Osipov
2014-06-14 16:47 ` Jeff Layton
0 siblings, 1 reply; 11+ messages in thread
From: Vitaly Osipov @ 2014-06-14 14:05 UTC (permalink / raw)
To: Jeff Layton; +Cc: Josh Triplett, Dan Carpenter, linux-sparse, Jeff Layton
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@poochiereds.net> wrote:
>
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression
2014-06-14 14:05 ` Vitaly Osipov
@ 2014-06-14 16:47 ` Jeff Layton
0 siblings, 0 replies; 11+ messages in thread
From: Jeff Layton @ 2014-06-14 16:47 UTC (permalink / raw)
To: Vitaly Osipov; +Cc: Josh Triplett, Dan Carpenter, linux-sparse, Jeff Layton
On Sun, 15 Jun 2014 00:05:22 +1000
Vitaly Osipov <vitaly.osipov@gmail.com> 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 <jlayton@poochiereds.net> wrote:
> >
> > 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>
--
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-06-14 16:47 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-10 21:38 [PATCH][RFC] err.h: silence sparse warning: dereference of noderef expression Jeff Layton
2014-06-11 5:45 ` Dan Carpenter
2014-06-11 11:06 ` Jeff Layton
2014-06-11 13:11 ` Dan Carpenter
2014-06-11 13:51 ` Jeff Layton
2014-06-12 8:06 ` Vitaly Osipov
2014-06-13 12:05 ` Jeff Layton
2014-06-13 15:56 ` Josh Triplett
2014-06-14 13:44 ` Jeff Layton
2014-06-14 14:05 ` Vitaly Osipov
2014-06-14 16:47 ` Jeff Layton
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.