Hi, kmemcheck is the kernel patch that detects use of uninitialized memory. kmemcheck reports eagerly, that is, any load of uninitialized memory will be reported, even though the bits in question will be thrown away later (before they are used in making a decision). One problem that we have encountered (which generates a false positive report) is that of bitfield accesses. In particular, whenever a bit of a bitfield is set (or cleared), the whole byte may be loaded before the specific bit is toggled. If the bitfield has not been accessed prior to this, it will of course load the uninitialized byte and report this to the user. One solution to the problem is to tell the compiler that the memory location in question is in fact uninitialized. This means that the compiler can optimize out the initial load (since it will be unused in either case), and no warning will be given by kmemcheck. One way to tell this to the compiler is to set all the members of the bitfield at once. We could do this unconditionally, although it adds some overhead on certain architectures, or we can do it for certain architectures only. My proposal is the attached patch -- a bitfields "API". Please see the patch description for a thorough explanation. (Please note that the patches do nothing unless the architecture is explicit about wanting the functionality. On i386, the second patch in the series would actually save 7 bytes, while on sparc it would take about 48 bytes _more_.) (The alternative to the patch is to explicitly initialize all the fields [including any leftover "padding" fields that must also be present] to zero at the same time, before copying in the new values. This seems a little excessive to me, and I believe that a single bitfield_begin_init() is neater and harder to break than an explicit [and seemingly meaningless] list of bitfield member initializations). So: How do you feel about this patch? It's all about making kmemcheck more useful... and not much else. Does it have any chance of entering the kernel along with kmemcheck (when/if that happens)? Thanks in advance. Vegard
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Linus Torvalds | Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview) |
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
git: | |
| Andi Kleen | [PATCH RFC] [4/9] modpost: Fix format string warnings |
| Rick Jones | Re: Network latency regressions from 2.6.22 to 2.6.29 |
| Antonio Almeida | HTB accuracy for high speed |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
