Re: The sheer number of sparse warnings in the kernel
On Wed, 26 Feb 2014 15:31:47 -0800, "H. Peter Anvin" said: > Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out > of date. With 0.5.0 I "only" see 8,207 messages, which means that at > least the linux/err.h issue is gone. Unfortunately, that's not true, at least with the Fedora Rawhide version of sparse. From yesterday's build of next-20140403: [/usr/src/linux-next] sparse --version 0.5.0 [/usr/src/linux-next] grep err.h build.default | sort | uniq -c 1491 include/linux/err.h:29:23: warning: dereference of noderef expression 2 include/linux/err.h:29:23: warning: too many warnings 2493 include/linux/err.h:34:16: warning: dereference of noderef expression 59 include/linux/err.h:39:17: warning: dereference of noderef expression 59 include/linux/err.h:39:24: warning: dereference of noderef expression 124 include/linux/err.h:52:25: warning: dereference of noderef expression 18 include/linux/err.h:57:20: warning: dereference of noderef expression 18 include/linux/err.h:58:32: warning: dereference of noderef expression (Oddly enough, the tarball in the .src.rpm seems to match the one on kernel.org, and nothing fishy in the .spec file, so I'm confused now...) pgpoqkv5RVxWi.pgp Description: PGP signature
Re: The sheer number of sparse warnings in the kernel
On Wed, 26 Feb 2014 15:31:47 -0800, H. Peter Anvin said: Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out of date. With 0.5.0 I only see 8,207 messages, which means that at least the linux/err.h issue is gone. Unfortunately, that's not true, at least with the Fedora Rawhide version of sparse. From yesterday's build of next-20140403: [/usr/src/linux-next] sparse --version 0.5.0 [/usr/src/linux-next] grep err.h build.default | sort | uniq -c 1491 include/linux/err.h:29:23: warning: dereference of noderef expression 2 include/linux/err.h:29:23: warning: too many warnings 2493 include/linux/err.h:34:16: warning: dereference of noderef expression 59 include/linux/err.h:39:17: warning: dereference of noderef expression 59 include/linux/err.h:39:24: warning: dereference of noderef expression 124 include/linux/err.h:52:25: warning: dereference of noderef expression 18 include/linux/err.h:57:20: warning: dereference of noderef expression 18 include/linux/err.h:58:32: warning: dereference of noderef expression (Oddly enough, the tarball in the .src.rpm seems to match the one on kernel.org, and nothing fishy in the .spec file, so I'm confused now...) pgpoqkv5RVxWi.pgp Description: PGP signature
Re: The sheer number of sparse warnings in the kernel
* H. Peter Anvin (h...@zytor.com) wrote: > The number of sparse errors in the current kernel is staggering, and it > makes sparse a lot less valuable of a tool that it otherwise could be. > On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. > Out of those, 12,358 come from linux/err.h. Given that the latter > basically spams *everything*, I can only conclude that almost noone uses > sparse unless they have a filter script. I did a bit of sparse fixing a few years ago; my strategy then was to get used to which types of warnings were more likely to be real and ignore all the rest - it was the only way to find anything useful from them. There were some that were very fruitful; the warnings for gfp_t types were great at spotting where someone had swapped the parameters to kmalloc for example. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
So getting this to the point where it is genuinely useful and can be made a ubiquitous part of the Linux development process is going to take more work and probably involve improvements to sparse so we can indicate in the kernel sources when something is okay or removing completely bogus warnings, and so on. Yes, for some areas of the kernel it will take some work, but for others, sparse works really well. As an example, building all of Works quite nicely for me. I run both spatch and smatch on drivers/hwmon and (partially) on drivers/watchdog. There is only one (false) warning in hwmon from spatch, plus about a dozen smatch warnings. I find it very valuable; even if warnings are false positives they often point to less than perfect code. I filter out some noise from smatch, but at least so far I did not have to do any filtering for spatch. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Thu, Feb 27, 2014 at 2:52 AM, Peter Hurley wrote:
>> The bigger question, again, is what do we need to do to make this
>> happen, assuming it is worth doing? We certainly have had bugs,
>> including security holes, which sparse would have caught. At the same
>> time, this kind of work tends to not be the kind that attract the top
>> hackers, unfortunately, as it is not "fun".
>
> Well there was that "should we do a bug-fix-only 4.0 release?" message
> from Linus back at the 3.12 release.
>
> Or do like Geert does with the build message regressions/fixes. I always
> scan
> that to make sure none of my work is in it :) (And that could be chunked
> up by maintainer).
A quick test shows that my scripts would catch (many) sparse errors and
warnings too, iff they would be in the kissb build logs.
So as soon as kissb starts building with C=1, we can start tracking sparse
regressions. The first report would contain _lots_ of regressions, though ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
Am 27.02.2014 00:25, schrieb Borislav Petkov: > On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: >> What do we need to do to actually make our tools be able to do work >> for us? Newbie projects to clean up? > > It certainly would be a much better way for newbies to get involved than > all the useless OCD-jerking off that floats back and forth nowadays. And > who knows, newbies might *actually* even learn something while doing > that. > > Btw, rw could help with the newbie project, I think. Yeah, on #kernelnewbies newbies often ask how they can help. Maybe a short info on http://kernelnewbies.org/ how to deal with sparse would help too. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
Am 27.02.2014 00:25, schrieb Borislav Petkov: On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: What do we need to do to actually make our tools be able to do work for us? Newbie projects to clean up? It certainly would be a much better way for newbies to get involved than all the useless OCD-jerking off that floats back and forth nowadays. And who knows, newbies might *actually* even learn something while doing that. Btw, rw could help with the newbie project, I think. Yeah, on #kernelnewbies newbies often ask how they can help. Maybe a short info on http://kernelnewbies.org/ how to deal with sparse would help too. Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Thu, Feb 27, 2014 at 2:52 AM, Peter Hurley pe...@hurleysoftware.com wrote:
The bigger question, again, is what do we need to do to make this
happen, assuming it is worth doing? We certainly have had bugs,
including security holes, which sparse would have caught. At the same
time, this kind of work tends to not be the kind that attract the top
hackers, unfortunately, as it is not fun.
Well there was that should we do a bug-fix-only 4.0 release? message
from Linus back at the 3.12 release.
Or do like Geert does with the build message regressions/fixes. I always
scan
that to make sure none of my work is in it :) (And that could be chunked
up by maintainer).
A quick test shows that my scripts would catch (many) sparse errors and
warnings too, iff they would be in the kissb build logs.
So as soon as kissb starts building with C=1, we can start tracking sparse
regressions. The first report would contain _lots_ of regressions, though ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
So getting this to the point where it is genuinely useful and can be made a ubiquitous part of the Linux development process is going to take more work and probably involve improvements to sparse so we can indicate in the kernel sources when something is okay or removing completely bogus warnings, and so on. Yes, for some areas of the kernel it will take some work, but for others, sparse works really well. As an example, building all of Works quite nicely for me. I run both spatch and smatch on drivers/hwmon and (partially) on drivers/watchdog. There is only one (false) warning in hwmon from spatch, plus about a dozen smatch warnings. I find it very valuable; even if warnings are false positives they often point to less than perfect code. I filter out some noise from smatch, but at least so far I did not have to do any filtering for spatch. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
* H. Peter Anvin (h...@zytor.com) wrote: The number of sparse errors in the current kernel is staggering, and it makes sparse a lot less valuable of a tool that it otherwise could be. On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. Out of those, 12,358 come from linux/err.h. Given that the latter basically spams *everything*, I can only conclude that almost noone uses sparse unless they have a filter script. I did a bit of sparse fixing a few years ago; my strategy then was to get used to which types of warnings were more likely to be real and ignore all the rest - it was the only way to find anything useful from them. There were some that were very fruitful; the warnings for gfp_t types were great at spotting where someone had swapped the parameters to kmalloc for example. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 10:15:08PM -0500, Dave Jones wrote: > On Wed, Feb 26, 2014 at 05:34:24PM -0800, Greg KH wrote: > > > Yes, for some areas of the kernel it will take some work, but for > > others, sparse works really well. As an example, building all of > > drivers/usb/* with sparse only brings up 2 issues, both of which should > > probably be fixed (or annotated properly in the case of the locking > > warning.) > > Hm. I see 102 in drivers/usb. Mostly in gadget. > http://paste.fedoraproject.org/80787/39347077/raw/ Ick, gadget, I don't build that for my systems as I don't have that hardware, sorry, I forgot to take that into consideration here. Hey, at least I know what I'm going to be doing tomorrow :) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 08:19:23PM -0800, H. Peter Anvin wrote: > On 02/26/2014 05:52 PM, Peter Hurley wrote: > > > > Well there was that "should we do a bug-fix-only 4.0 release?" message > > from Linus back at the 3.12 release. > > > > Sure... but will it actually happen? I sure hope not, the backlog it would cause would be immense. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 05:52 PM, Peter Hurley wrote: > > Well there was that "should we do a bug-fix-only 4.0 release?" message > from Linus back at the 3.12 release. > Sure... but will it actually happen? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 05:34:24PM -0800, Greg KH wrote: > Yes, for some areas of the kernel it will take some work, but for > others, sparse works really well. As an example, building all of > drivers/usb/* with sparse only brings up 2 issues, both of which should > probably be fixed (or annotated properly in the case of the locking > warning.) Hm. I see 102 in drivers/usb. Mostly in gadget. http://paste.fedoraproject.org/80787/39347077/raw/ (Note that some of those are duplicates, which would be nice if sparse would be quieter about) Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, 2014-02-26 at 17:34 -0800, Greg KH wrote: > On Wed, Feb 26, 2014 at 04:11:30PM -0800, H. Peter Anvin wrote: > > I have seen this phenomenon, too. I also see a bunch of sparse warnings > > which are clearly bogus, for example complaining about sizeof(bool) when > > in bits like: > > > > __this_cpu_write(swallow_nmi, false); [] > I guess the first thing would be to do is look to try to fix things like > the "bool" issue you have here. I wonder what the "fix" would be as by standard _Bool doesn't have a defined size. Probably another sparse -Wno-sizeof-bool flag. (just added and submitted) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 07:11 PM, H. Peter Anvin wrote: On 02/26/2014 03:28 PM, Greg KH wrote: What do we need to do to actually make our tools be able to do work for us? Newbie projects to clean up? Trying to get the larger Linux companies to put resources on it? It's not the easiest "newbie" project as usually the first reflex to "just cast it away" is wrong for a lot of sparse warnings. I know this from people trying to fix up the sparse warnings in drivers/staging/ I have seen this phenomenon, too. I also see a bunch of sparse warnings which are clearly bogus, for example complaining about sizeof(bool) when in bits like: __this_cpu_write(swallow_nmi, false); So getting this to the point where it is genuinely useful and can be made a ubiquitous part of the Linux development process is going to take more work and probably involve improvements to sparse so we can indicate in the kernel sources when something is okay or removing completely bogus warnings, and so on. The bigger question, again, is what do we need to do to make this happen, assuming it is worth doing? We certainly have had bugs, including security holes, which sparse would have caught. At the same time, this kind of work tends to not be the kind that attract the top hackers, unfortunately, as it is not "fun". Well there was that "should we do a bug-fix-only 4.0 release?" message from Linus back at the 3.12 release. Or do like Geert does with the build message regressions/fixes. I always scan that to make sure none of my work is in it :) (And that could be chunked up by maintainer). Just a thought. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 04:11:30PM -0800, H. Peter Anvin wrote: > On 02/26/2014 03:28 PM, Greg KH wrote: > >> > >> What do we need to do to actually make our tools be able to do work for > >> us? Newbie projects to clean up? Trying to get the larger Linux > >> companies to put resources on it? > > > > It's not the easiest "newbie" project as usually the first reflex to > > "just cast it away" is wrong for a lot of sparse warnings. I know this > > from people trying to fix up the sparse warnings in drivers/staging/ > > > > I have seen this phenomenon, too. I also see a bunch of sparse warnings > which are clearly bogus, for example complaining about sizeof(bool) when > in bits like: > > __this_cpu_write(swallow_nmi, false); > > So getting this to the point where it is genuinely useful and can be > made a ubiquitous part of the Linux development process is going to take > more work and probably involve improvements to sparse so we can indicate > in the kernel sources when something is okay or removing completely > bogus warnings, and so on. Yes, for some areas of the kernel it will take some work, but for others, sparse works really well. As an example, building all of drivers/usb/* with sparse only brings up 2 issues, both of which should probably be fixed (or annotated properly in the case of the locking warning.) So keeping things "sparse clean" there is quite easy and part of taking new patches. > The bigger question, again, is what do we need to do to make this > happen, assuming it is worth doing? We certainly have had bugs, > including security holes, which sparse would have caught. At the same > time, this kind of work tends to not be the kind that attract the top > hackers, unfortunately, as it is not "fun". I guess the first thing would be to do is look to try to fix things like the "bool" issue you have here. And just grind away at the issues, one by one. Some of us like doing those types of things, so I'm sure you can find people willing to do it if you get the word out. Once we hit a "tipping point" of the kernel being almost sparse clean, having the main subsystem maintainers always run it would be good. I know the 0-day bot runs it, as I get patches all the time from it to fix up some sparse warnings. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
That would be good. On February 26, 2014 5:19:51 PM PST, Josh Boyer wrote: >On Wed, Feb 26, 2014 at 6:37 PM, H. Peter Anvin wrote: >> On 02/26/2014 03:31 PM, H. Peter Anvin wrote: >>> On 02/26/2014 03:29 PM, Greg KH wrote: On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: > On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: >> The number of sparse errors in the current kernel is staggering, >and it >> makes sparse a lot less valuable of a tool that it otherwise >could be. >> On a build of x86-64 allyesconfig I'm getting 20,676 sparse >messages. >> Out of those, 12,358 come from linux/err.h. Given that the >latter >> basically spams *everything*, I can only conclude that almost >noone uses >> sparse unless they have a filter script. > > What errors are you seeing from err.h? I don't see those when >building > different subdirectories with sparse (which is how I normally use >it.) > > And what version of sparse are you running: > $ sparse --version > v0.4.5-rc1-407-g345e8943fc36 Ah, 0.5.0 is now out, maybe you should update to that version? >>> >>> Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed >out >>> of date. With 0.5.0 I "only" see 8,207 messages, which means that >at >>> least the linux/err.h issue is gone. >>> >> >> For what it's worth, the rpm is called sparse-0.4.5.rc1-2.fc19.x86_64 >> and sparse --version reports 0.4.4... > >Fedora rawhide has sparse-0.5.0-1.fc21. If it matters, we could >probably update F20 and F19 with that. > >josh -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 6:37 PM, H. Peter Anvin wrote: > On 02/26/2014 03:31 PM, H. Peter Anvin wrote: >> On 02/26/2014 03:29 PM, Greg KH wrote: >>> On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: > The number of sparse errors in the current kernel is staggering, and it > makes sparse a lot less valuable of a tool that it otherwise could be. > On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. > Out of those, 12,358 come from linux/err.h. Given that the latter > basically spams *everything*, I can only conclude that almost noone uses > sparse unless they have a filter script. What errors are you seeing from err.h? I don't see those when building different subdirectories with sparse (which is how I normally use it.) And what version of sparse are you running: $ sparse --version v0.4.5-rc1-407-g345e8943fc36 >>> >>> Ah, 0.5.0 is now out, maybe you should update to that version? >>> >> >> Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out >> of date. With 0.5.0 I "only" see 8,207 messages, which means that at >> least the linux/err.h issue is gone. >> > > For what it's worth, the rpm is called sparse-0.4.5.rc1-2.fc19.x86_64 > and sparse --version reports 0.4.4... Fedora rawhide has sparse-0.5.0-1.fc21. If it matters, we could probably update F20 and F19 with that. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, 2014-02-26 at 16:51 -0800, H. Peter Anvin wrote: > On 02/26/2014 04:48 PM, Joe Perches wrote: > > err.h could also return bool instead of long for the > > IS_ERR and IS_ERR_OR_NULL tests. > > This is definitely true... although we should check that that doesn't > make the code worse as this is used *all over* the kernel. I tested using arch/x86/crypto/ x86-64 and 32 and there are no .o file differences using bool or long via objdump -d new and old > > Maybe something like this could be useful. > > > > Shut up the unsigned<->signed pointer conversions > > and implicit conversions in the Makefile. > > Sounds like two separate patches to me. Yeah, it was just for discussion. I think gcc 4.8 is overly noisy about those 2. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 04:48 PM, Joe Perches wrote: > err.h could also return bool instead of long for the > IS_ERR and IS_ERR_OR_NULL tests. This is definitely true... although we should check that that doesn't make the code worse as this is used *all over* the kernel. > Maybe something like this could be useful. > > Shut up the unsigned<->signed pointer conversions > and implicit conversions in the Makefile. Sounds like two separate patches to me. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, 2014-02-26 at 14:49 -0800, H. Peter Anvin wrote:
> The number of sparse errors in the current kernel is staggering, and it
> makes sparse a lot less valuable of a tool that it otherwise could be.
> On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages.
> Out of those, 12,358 come from linux/err.h. Given that the latter
> basically spams *everything*, I can only conclude that almost noone uses
> sparse unless they have a filter script.
>
> So a lot of these are certainly nuisance problems, like the
> stuff which has to do with the handling of error values,
> but some of these look like real bugs.
>
> What do we need to do to actually make our tools be able to do work for
> us? Newbie projects to clean up? Trying to get the larger Linux
> companies to put resources on it?
gcc 4.8 does annoyingly warn on all unsigned/signed
mismatches/implicit conversions too.
err.h could also return bool instead of long for the
IS_ERR and IS_ERR_OR_NULL tests.
Maybe something like this could be useful.
Shut up the unsigned<->signed pointer conversions
and implicit conversions in the Makefile.
Use bool not long for IS_ERR and IS_ERR_OR_NULL
Update the dentry description of kernel pointers
left over from 2002's move to err.h
unsigned...
---
Makefile| 1 +
include/linux/err.h | 7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index fce2ba7..a9c11c4 100644
--- a/Makefile
+++ b/Makefile
@@ -381,6 +381,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
+ -Wno-sign-conversion -Wno-pointer-sign \
-Wno-format-security \
-fno-delete-null-pointer-checks
KBUILD_AFLAGS_KERNEL :=
diff --git a/include/linux/err.h b/include/linux/err.h
index 15f92e0..a729120 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -2,12 +2,13 @@
#define _LINUX_ERR_H
#include
+#include
#include
/*
* Kernel pointers have redundant information, so we can use a
- * scheme where we can return either an error code or a dentry
+ * scheme where we can return either an error code or a normal
* pointer with the same return value.
*
* This should be a per-architecture thing, to allow different
@@ -29,12 +30,12 @@ static inline long __must_check PTR_ERR(__force const void
*ptr)
return (long) ptr;
}
-static inline long __must_check IS_ERR(__force const void *ptr)
+static inline bool __must_check IS_ERR(__force const void *ptr)
{
return IS_ERR_VALUE((unsigned long)ptr);
}
-static inline long __must_check IS_ERR_OR_NULL(__force const void *ptr)
+static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
{
return !ptr || IS_ERR_VALUE((unsigned long)ptr);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 03:28 PM, Greg KH wrote: >> >> What do we need to do to actually make our tools be able to do work for >> us? Newbie projects to clean up? Trying to get the larger Linux >> companies to put resources on it? > > It's not the easiest "newbie" project as usually the first reflex to > "just cast it away" is wrong for a lot of sparse warnings. I know this > from people trying to fix up the sparse warnings in drivers/staging/ > I have seen this phenomenon, too. I also see a bunch of sparse warnings which are clearly bogus, for example complaining about sizeof(bool) when in bits like: __this_cpu_write(swallow_nmi, false); So getting this to the point where it is genuinely useful and can be made a ubiquitous part of the Linux development process is going to take more work and probably involve improvements to sparse so we can indicate in the kernel sources when something is okay or removing completely bogus warnings, and so on. The bigger question, again, is what do we need to do to make this happen, assuming it is worth doing? We certainly have had bugs, including security holes, which sparse would have caught. At the same time, this kind of work tends to not be the kind that attract the top hackers, unfortunately, as it is not "fun". -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 03:31 PM, H. Peter Anvin wrote: > On 02/26/2014 03:29 PM, Greg KH wrote: >> On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: >>> On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: The number of sparse errors in the current kernel is staggering, and it makes sparse a lot less valuable of a tool that it otherwise could be. On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. Out of those, 12,358 come from linux/err.h. Given that the latter basically spams *everything*, I can only conclude that almost noone uses sparse unless they have a filter script. >>> >>> What errors are you seeing from err.h? I don't see those when building >>> different subdirectories with sparse (which is how I normally use it.) >>> >>> And what version of sparse are you running: >>> $ sparse --version >>> v0.4.5-rc1-407-g345e8943fc36 >> >> Ah, 0.5.0 is now out, maybe you should update to that version? >> > > Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out > of date. With 0.5.0 I "only" see 8,207 messages, which means that at > least the linux/err.h issue is gone. > For what it's worth, the rpm is called sparse-0.4.5.rc1-2.fc19.x86_64 and sparse --version reports 0.4.4... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 03:29 PM, Greg KH wrote: > On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: >> On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: >>> The number of sparse errors in the current kernel is staggering, and it >>> makes sparse a lot less valuable of a tool that it otherwise could be. >>> On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. >>> Out of those, 12,358 come from linux/err.h. Given that the latter >>> basically spams *everything*, I can only conclude that almost noone uses >>> sparse unless they have a filter script. >> >> What errors are you seeing from err.h? I don't see those when building >> different subdirectories with sparse (which is how I normally use it.) >> >> And what version of sparse are you running: >> $ sparse --version >> v0.4.5-rc1-407-g345e8943fc36 > > Ah, 0.5.0 is now out, maybe you should update to that version? > Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out of date. With 0.5.0 I "only" see 8,207 messages, which means that at least the linux/err.h issue is gone. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: > On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: > > The number of sparse errors in the current kernel is staggering, and it > > makes sparse a lot less valuable of a tool that it otherwise could be. > > On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. > > Out of those, 12,358 come from linux/err.h. Given that the latter > > basically spams *everything*, I can only conclude that almost noone uses > > sparse unless they have a filter script. > > What errors are you seeing from err.h? I don't see those when building > different subdirectories with sparse (which is how I normally use it.) > > And what version of sparse are you running: > $ sparse --version > v0.4.5-rc1-407-g345e8943fc36 Ah, 0.5.0 is now out, maybe you should update to that version? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: > The number of sparse errors in the current kernel is staggering, and it > makes sparse a lot less valuable of a tool that it otherwise could be. > On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. > Out of those, 12,358 come from linux/err.h. Given that the latter > basically spams *everything*, I can only conclude that almost noone uses > sparse unless they have a filter script. What errors are you seeing from err.h? I don't see those when building different subdirectories with sparse (which is how I normally use it.) And what version of sparse are you running: $ sparse --version v0.4.5-rc1-407-g345e8943fc36 > So a lot of these are certainly nuisance problems, like the > stuff which has to do with the handling of error values, > but some of these look like real bugs. > > What do we need to do to actually make our tools be able to do work for > us? Newbie projects to clean up? Trying to get the larger Linux > companies to put resources on it? It's not the easiest "newbie" project as usually the first reflex to "just cast it away" is wrong for a lot of sparse warnings. I know this from people trying to fix up the sparse warnings in drivers/staging/ thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: > What do we need to do to actually make our tools be able to do work > for us? Newbie projects to clean up? It certainly would be a much better way for newbies to get involved than all the useless OCD-jerking off that floats back and forth nowadays. And who knows, newbies might *actually* even learn something while doing that. Btw, rw could help with the newbie project, I think. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: What do we need to do to actually make our tools be able to do work for us? Newbie projects to clean up? It certainly would be a much better way for newbies to get involved than all the useless OCD-jerking off that floats back and forth nowadays. And who knows, newbies might *actually* even learn something while doing that. Btw, rw could help with the newbie project, I think. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: The number of sparse errors in the current kernel is staggering, and it makes sparse a lot less valuable of a tool that it otherwise could be. On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. Out of those, 12,358 come from linux/err.h. Given that the latter basically spams *everything*, I can only conclude that almost noone uses sparse unless they have a filter script. What errors are you seeing from err.h? I don't see those when building different subdirectories with sparse (which is how I normally use it.) And what version of sparse are you running: $ sparse --version v0.4.5-rc1-407-g345e8943fc36 So a lot of these are certainly nuisance problems, like the linux/err.h stuff which has to do with the handling of error values, but some of these look like real bugs. What do we need to do to actually make our tools be able to do work for us? Newbie projects to clean up? Trying to get the larger Linux companies to put resources on it? It's not the easiest newbie project as usually the first reflex to just cast it away is wrong for a lot of sparse warnings. I know this from people trying to fix up the sparse warnings in drivers/staging/ thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: The number of sparse errors in the current kernel is staggering, and it makes sparse a lot less valuable of a tool that it otherwise could be. On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. Out of those, 12,358 come from linux/err.h. Given that the latter basically spams *everything*, I can only conclude that almost noone uses sparse unless they have a filter script. What errors are you seeing from err.h? I don't see those when building different subdirectories with sparse (which is how I normally use it.) And what version of sparse are you running: $ sparse --version v0.4.5-rc1-407-g345e8943fc36 Ah, 0.5.0 is now out, maybe you should update to that version? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 03:29 PM, Greg KH wrote: On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: The number of sparse errors in the current kernel is staggering, and it makes sparse a lot less valuable of a tool that it otherwise could be. On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. Out of those, 12,358 come from linux/err.h. Given that the latter basically spams *everything*, I can only conclude that almost noone uses sparse unless they have a filter script. What errors are you seeing from err.h? I don't see those when building different subdirectories with sparse (which is how I normally use it.) And what version of sparse are you running: $ sparse --version v0.4.5-rc1-407-g345e8943fc36 Ah, 0.5.0 is now out, maybe you should update to that version? Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out of date. With 0.5.0 I only see 8,207 messages, which means that at least the linux/err.h issue is gone. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 03:31 PM, H. Peter Anvin wrote: On 02/26/2014 03:29 PM, Greg KH wrote: On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: The number of sparse errors in the current kernel is staggering, and it makes sparse a lot less valuable of a tool that it otherwise could be. On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. Out of those, 12,358 come from linux/err.h. Given that the latter basically spams *everything*, I can only conclude that almost noone uses sparse unless they have a filter script. What errors are you seeing from err.h? I don't see those when building different subdirectories with sparse (which is how I normally use it.) And what version of sparse are you running: $ sparse --version v0.4.5-rc1-407-g345e8943fc36 Ah, 0.5.0 is now out, maybe you should update to that version? Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out of date. With 0.5.0 I only see 8,207 messages, which means that at least the linux/err.h issue is gone. For what it's worth, the rpm is called sparse-0.4.5.rc1-2.fc19.x86_64 and sparse --version reports 0.4.4... -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 03:28 PM, Greg KH wrote: What do we need to do to actually make our tools be able to do work for us? Newbie projects to clean up? Trying to get the larger Linux companies to put resources on it? It's not the easiest newbie project as usually the first reflex to just cast it away is wrong for a lot of sparse warnings. I know this from people trying to fix up the sparse warnings in drivers/staging/ I have seen this phenomenon, too. I also see a bunch of sparse warnings which are clearly bogus, for example complaining about sizeof(bool) when in bits like: __this_cpu_write(swallow_nmi, false); So getting this to the point where it is genuinely useful and can be made a ubiquitous part of the Linux development process is going to take more work and probably involve improvements to sparse so we can indicate in the kernel sources when something is okay or removing completely bogus warnings, and so on. The bigger question, again, is what do we need to do to make this happen, assuming it is worth doing? We certainly have had bugs, including security holes, which sparse would have caught. At the same time, this kind of work tends to not be the kind that attract the top hackers, unfortunately, as it is not fun. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, 2014-02-26 at 14:49 -0800, H. Peter Anvin wrote:
The number of sparse errors in the current kernel is staggering, and it
makes sparse a lot less valuable of a tool that it otherwise could be.
On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages.
Out of those, 12,358 come from linux/err.h. Given that the latter
basically spams *everything*, I can only conclude that almost noone uses
sparse unless they have a filter script.
So a lot of these are certainly nuisance problems, like the
linux/err.h stuff which has to do with the handling of error values,
but some of these look like real bugs.
What do we need to do to actually make our tools be able to do work for
us? Newbie projects to clean up? Trying to get the larger Linux
companies to put resources on it?
gcc 4.8 does annoyingly warn on all unsigned/signed
mismatches/implicit conversions too.
err.h could also return bool instead of long for the
IS_ERR and IS_ERR_OR_NULL tests.
Maybe something like this could be useful.
Shut up the unsigned-signed pointer conversions
and implicit conversions in the Makefile.
Use bool not long for IS_ERR and IS_ERR_OR_NULL
Update the dentry description of kernel pointers
left over from 2002's move to err.h
unsigned...
---
Makefile| 1 +
include/linux/err.h | 7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index fce2ba7..a9c11c4 100644
--- a/Makefile
+++ b/Makefile
@@ -381,6 +381,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
+ -Wno-sign-conversion -Wno-pointer-sign \
-Wno-format-security \
-fno-delete-null-pointer-checks
KBUILD_AFLAGS_KERNEL :=
diff --git a/include/linux/err.h b/include/linux/err.h
index 15f92e0..a729120 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -2,12 +2,13 @@
#define _LINUX_ERR_H
#include linux/compiler.h
+#include linux/types.h
#include asm/errno.h
/*
* Kernel pointers have redundant information, so we can use a
- * scheme where we can return either an error code or a dentry
+ * scheme where we can return either an error code or a normal
* pointer with the same return value.
*
* This should be a per-architecture thing, to allow different
@@ -29,12 +30,12 @@ static inline long __must_check PTR_ERR(__force const void
*ptr)
return (long) ptr;
}
-static inline long __must_check IS_ERR(__force const void *ptr)
+static inline bool __must_check IS_ERR(__force const void *ptr)
{
return IS_ERR_VALUE((unsigned long)ptr);
}
-static inline long __must_check IS_ERR_OR_NULL(__force const void *ptr)
+static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
{
return !ptr || IS_ERR_VALUE((unsigned long)ptr);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 04:48 PM, Joe Perches wrote: err.h could also return bool instead of long for the IS_ERR and IS_ERR_OR_NULL tests. This is definitely true... although we should check that that doesn't make the code worse as this is used *all over* the kernel. Maybe something like this could be useful. Shut up the unsigned-signed pointer conversions and implicit conversions in the Makefile. Sounds like two separate patches to me. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, 2014-02-26 at 16:51 -0800, H. Peter Anvin wrote: On 02/26/2014 04:48 PM, Joe Perches wrote: err.h could also return bool instead of long for the IS_ERR and IS_ERR_OR_NULL tests. This is definitely true... although we should check that that doesn't make the code worse as this is used *all over* the kernel. I tested using arch/x86/crypto/ x86-64 and 32 and there are no .o file differences using bool or long via objdump -d new and old Maybe something like this could be useful. Shut up the unsigned-signed pointer conversions and implicit conversions in the Makefile. Sounds like two separate patches to me. Yeah, it was just for discussion. I think gcc 4.8 is overly noisy about those 2. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 6:37 PM, H. Peter Anvin h...@zytor.com wrote: On 02/26/2014 03:31 PM, H. Peter Anvin wrote: On 02/26/2014 03:29 PM, Greg KH wrote: On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: The number of sparse errors in the current kernel is staggering, and it makes sparse a lot less valuable of a tool that it otherwise could be. On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. Out of those, 12,358 come from linux/err.h. Given that the latter basically spams *everything*, I can only conclude that almost noone uses sparse unless they have a filter script. What errors are you seeing from err.h? I don't see those when building different subdirectories with sparse (which is how I normally use it.) And what version of sparse are you running: $ sparse --version v0.4.5-rc1-407-g345e8943fc36 Ah, 0.5.0 is now out, maybe you should update to that version? Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out of date. With 0.5.0 I only see 8,207 messages, which means that at least the linux/err.h issue is gone. For what it's worth, the rpm is called sparse-0.4.5.rc1-2.fc19.x86_64 and sparse --version reports 0.4.4... Fedora rawhide has sparse-0.5.0-1.fc21. If it matters, we could probably update F20 and F19 with that. josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
That would be good. On February 26, 2014 5:19:51 PM PST, Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Feb 26, 2014 at 6:37 PM, H. Peter Anvin h...@zytor.com wrote: On 02/26/2014 03:31 PM, H. Peter Anvin wrote: On 02/26/2014 03:29 PM, Greg KH wrote: On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote: On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote: The number of sparse errors in the current kernel is staggering, and it makes sparse a lot less valuable of a tool that it otherwise could be. On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages. Out of those, 12,358 come from linux/err.h. Given that the latter basically spams *everything*, I can only conclude that almost noone uses sparse unless they have a filter script. What errors are you seeing from err.h? I don't see those when building different subdirectories with sparse (which is how I normally use it.) And what version of sparse are you running: $ sparse --version v0.4.5-rc1-407-g345e8943fc36 Ah, 0.5.0 is now out, maybe you should update to that version? Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out of date. With 0.5.0 I only see 8,207 messages, which means that at least the linux/err.h issue is gone. For what it's worth, the rpm is called sparse-0.4.5.rc1-2.fc19.x86_64 and sparse --version reports 0.4.4... Fedora rawhide has sparse-0.5.0-1.fc21. If it matters, we could probably update F20 and F19 with that. josh -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 04:11:30PM -0800, H. Peter Anvin wrote: On 02/26/2014 03:28 PM, Greg KH wrote: What do we need to do to actually make our tools be able to do work for us? Newbie projects to clean up? Trying to get the larger Linux companies to put resources on it? It's not the easiest newbie project as usually the first reflex to just cast it away is wrong for a lot of sparse warnings. I know this from people trying to fix up the sparse warnings in drivers/staging/ I have seen this phenomenon, too. I also see a bunch of sparse warnings which are clearly bogus, for example complaining about sizeof(bool) when in bits like: __this_cpu_write(swallow_nmi, false); So getting this to the point where it is genuinely useful and can be made a ubiquitous part of the Linux development process is going to take more work and probably involve improvements to sparse so we can indicate in the kernel sources when something is okay or removing completely bogus warnings, and so on. Yes, for some areas of the kernel it will take some work, but for others, sparse works really well. As an example, building all of drivers/usb/* with sparse only brings up 2 issues, both of which should probably be fixed (or annotated properly in the case of the locking warning.) So keeping things sparse clean there is quite easy and part of taking new patches. The bigger question, again, is what do we need to do to make this happen, assuming it is worth doing? We certainly have had bugs, including security holes, which sparse would have caught. At the same time, this kind of work tends to not be the kind that attract the top hackers, unfortunately, as it is not fun. I guess the first thing would be to do is look to try to fix things like the bool issue you have here. And just grind away at the issues, one by one. Some of us like doing those types of things, so I'm sure you can find people willing to do it if you get the word out. Once we hit a tipping point of the kernel being almost sparse clean, having the main subsystem maintainers always run it would be good. I know the 0-day bot runs it, as I get patches all the time from it to fix up some sparse warnings. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 07:11 PM, H. Peter Anvin wrote: On 02/26/2014 03:28 PM, Greg KH wrote: What do we need to do to actually make our tools be able to do work for us? Newbie projects to clean up? Trying to get the larger Linux companies to put resources on it? It's not the easiest newbie project as usually the first reflex to just cast it away is wrong for a lot of sparse warnings. I know this from people trying to fix up the sparse warnings in drivers/staging/ I have seen this phenomenon, too. I also see a bunch of sparse warnings which are clearly bogus, for example complaining about sizeof(bool) when in bits like: __this_cpu_write(swallow_nmi, false); So getting this to the point where it is genuinely useful and can be made a ubiquitous part of the Linux development process is going to take more work and probably involve improvements to sparse so we can indicate in the kernel sources when something is okay or removing completely bogus warnings, and so on. The bigger question, again, is what do we need to do to make this happen, assuming it is worth doing? We certainly have had bugs, including security holes, which sparse would have caught. At the same time, this kind of work tends to not be the kind that attract the top hackers, unfortunately, as it is not fun. Well there was that should we do a bug-fix-only 4.0 release? message from Linus back at the 3.12 release. Or do like Geert does with the build message regressions/fixes. I always scan that to make sure none of my work is in it :) (And that could be chunked up by maintainer). Just a thought. Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, 2014-02-26 at 17:34 -0800, Greg KH wrote: On Wed, Feb 26, 2014 at 04:11:30PM -0800, H. Peter Anvin wrote: I have seen this phenomenon, too. I also see a bunch of sparse warnings which are clearly bogus, for example complaining about sizeof(bool) when in bits like: __this_cpu_write(swallow_nmi, false); [] I guess the first thing would be to do is look to try to fix things like the bool issue you have here. I wonder what the fix would be as by standard _Bool doesn't have a defined size. Probably another sparse -Wno-sizeof-bool flag. (just added and submitted) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 05:34:24PM -0800, Greg KH wrote: Yes, for some areas of the kernel it will take some work, but for others, sparse works really well. As an example, building all of drivers/usb/* with sparse only brings up 2 issues, both of which should probably be fixed (or annotated properly in the case of the locking warning.) Hm. I see 102 in drivers/usb. Mostly in gadget. http://paste.fedoraproject.org/80787/39347077/raw/ (Note that some of those are duplicates, which would be nice if sparse would be quieter about) Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On 02/26/2014 05:52 PM, Peter Hurley wrote: Well there was that should we do a bug-fix-only 4.0 release? message from Linus back at the 3.12 release. Sure... but will it actually happen? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 08:19:23PM -0800, H. Peter Anvin wrote: On 02/26/2014 05:52 PM, Peter Hurley wrote: Well there was that should we do a bug-fix-only 4.0 release? message from Linus back at the 3.12 release. Sure... but will it actually happen? I sure hope not, the backlog it would cause would be immense. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The sheer number of sparse warnings in the kernel
On Wed, Feb 26, 2014 at 10:15:08PM -0500, Dave Jones wrote: On Wed, Feb 26, 2014 at 05:34:24PM -0800, Greg KH wrote: Yes, for some areas of the kernel it will take some work, but for others, sparse works really well. As an example, building all of drivers/usb/* with sparse only brings up 2 issues, both of which should probably be fixed (or annotated properly in the case of the locking warning.) Hm. I see 102 in drivers/usb. Mostly in gadget. http://paste.fedoraproject.org/80787/39347077/raw/ Ick, gadget, I don't build that for my systems as I don't have that hardware, sorry, I forgot to take that into consideration here. Hey, at least I know what I'm going to be doing tomorrow :) greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
