On Thu, Feb 14, 2008 at 10:49 PM, Andi Kleen <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/