Re: [PATCH 4/4] kmemcheck v4

["Vegard Nossum" <vegard.nossum@gmail.com>]

On Thu, Feb 14, 2008 at 10:49 PM, Andi Kleen <andi@firstfloor.org> wrote:
>  The ifdefs are quite ugly. I would recommend to define standard
>  functions (kmemcheck_init_zero or similar and an own __GFP flag) that can
>  be used without ifdef and easily nop'ed out on !KMEMCHECK kernels.

Yes, they are. We do in fact have a flag for this purpose,
__GFP_NOTRACK (or SLAB_NOTRACK for entire slab caches). I have now
changed some of the hunks to use this method instead of ifdefs. Thanks
for pointing this out.

Also note that this patch is not meant to be a part of kmemcheck
itself; it simply silences some of the (some bogus) warnings.
Preferably, each one of these call-sites should be carefully audited
and "fixed" independently of kmemcheck itself. In fact, the patch
should probably be split, one for the bogus warnings (where the
bogus-warning fixes are no-ops if kmemcheck is disabled), and the real
errors in their own patches.

There is currently a huge problem with bit-fields. When bit-fields are
initialized, gcc may use the AND/OR instructions to initialize one
field at a time (depending on what the C code looks like, of course).
This is seen by kmemcheck as 1. full 8/16/32-bit read 2. full
8/16/32-bit write. Therefore the first initialization of (access to) a
bit-field variable will generally cause a warning from kmemcheck. And
this is perfectly legal from the compiler point of view.

Ingo's approach so far has been to initialize all the bit-field
variables at once. This is probably what the author of the original
code wants to do anyway, though not in all cases. I admit that I am
not confident enough with kernel code myself to decide what the
appropriate fix would be in most cases of kmemcheck warnings.
Therefore, take this last patch with a grain of salt (for now).

Thank you.


Vegard