lkml.org 
[lkml]   [2008]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4] kmemcheck v4
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


\
 
 \ /
  Last update: 2008-02-15 20:21    [W:1.755 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site