Alexander Viro wrote:
>
> On Tue, 9 Jul 2002, Arnaldo Carvalho de Melo wrote:
>
>>Em Tue, Jul 09, 2002 at 02:47:49PM -0700, Robert Love escreveu:
>>
>>>On Tue, 2002-07-09 at 07:44, Dave Hansen wrote:
>>>
>>>>The Stanford Checker or something resembling it would be invaluable
>>>>here. It would be a hell of a lot better than my litle patch!
>>>
>>>The Stanford Checker would be infinitely invaluable here -- agreed.
>>>
>>>Anything that can graph call chains and do analysis... we can get it to
>>>tell us exactly who and what.
>
> Not anything. It can be used to find problems (and be very helpful at that)
> but it can't be used to verify anything.
>
> The problem is that checker doesn't (and cannot) cover all code paths -
> by the time when it comes into the game the source had already passed
> through through cpp. In other words, depending on the configuration
> you might get very different results.
I have the feeling that the filesystems' use of lots of function
pointers will add a large amount of complexity to whatever programming
any checker would require. Bill Irwin and I were discussing it and we
have ways of getting around most of them, but there are _lots_ of
special cases.
"Proving" correctness would obviously be ideal, but in an imperfect
world, what are your feelings on a runtime system for detecting
"magical/bad" BKL use? I'm not proposing my kludgy "printk if you're
bad" stuff, but something with much less impact. I would like to do
something somewhat like profile=2. During each lock_kernel(), the
program counter (any maybe more) could be stored in an internal kernel
structure and retrieved later via a /proc file, just like readprofile.
This wouldn't have intrusive printk messages, and would be able to
be activated by either a command-line parameter, or something else in
/proc. If we had this in our development kernel, interested
developers could pay attention to the output, while the normal kernel
developer could simply ignore it.
> Normally it's not that bad, but "can this function block?" is very nasty
> in that respect - changes of configuration can and do affect that in
> non-trivial ways.
I also wonder how it handles things like kmalloc(), which can block
depending on arguments.
--
Dave Hansen
[email protected]
On Tue, 9 Jul 2002, Dave Hansen wrote:
> I have the feeling that the filesystems' use of lots of function
> pointers will add a large amount of complexity to whatever programming
> any checker would require. Bill Irwin and I were discussing it and we
> have ways of getting around most of them, but there are _lots_ of
> special cases.
The real complexity is _not_ on compiler level. Checker manages that
quite fine. The problem is in the coverage - making sure that code
gets to compiler is much, much more painful.
> > Normally it's not that bad, but "can this function block?" is very nasty
> > in that respect - changes of configuration can and do affect that in
> > non-trivial ways.
>
> I also wonder how it handles things like kmalloc(), which can block
> depending on arguments.
Not a big deal - checker can be taught how kmalloc() works (normally we
either pass it explict constant or an argument of calling function -
without any changes).
Again, the real mess is due to the way we use cpp. It would be wonderful if
we had 4-6 options really affecting stuff (changing structure sizes, etc.)
and everything else would be handled either on compiler (
if (CONFIG_FOO) {
...
}
and let compiler eliminate dead branches) or on the linker (
obj-$(CONFIG_BAR) += bar.o
) level. Then the life would be _way_ easier and we would really have
a chance to do a meaningful coverage.
As it is, we have way too many ifdefs to hope that any automated tool
would be able to cope with the damn thing. It used to be worse -
these days several really nasty piles of ifdefs are gone. However,
we still have quite a few remaining.
Quick-and-dirty search shows ~1.2e4 ifdefs on CONFIG_... in the tree.
Most of them - patently ridiculous (random example: fs/ncpfs/symlink.c
/*
<usual comments in the beginning>
*/
#include <linux/config.h>
#ifdef CONFIG_NCPFS_EXTRAS
<lots of stuff>
#endif
/* ----- EOF ----- */
which should be
ifneq ($(CONFIG_NCPFS_EXTRAS),n)
ifneq ($(CONFIG_NCPFS_EXTRAS),)
ncpfs-objs += symlink.o
endif
endif
in Makefile and none of the crap in symlink.c).
However, there's really bad stuff and it also has to be dealt with...