On Sun, Feb 22, 2009 at 08:42:37PM +0100, Frederic Weisbecker wrote: > On Sun, Feb 22, 2009 at 08:27:38PM +0100, Jiri Slaby wrote: > > On 22.2.2009 18:10, Frederic Weisbecker wrote: > >> I have some troubles with kmemcheck, so I give up for now. > >> Well, by reading the kmemcheck documentation, it tells that there can be some false > >> positives so... > > > > This has nothing to do with kmemcheck. > > > >> Since we are not sure this is a real bug, I'm not sure it would be interesting. > > > > There is no false positive possibility with these checkers, so this is > > pretty much interesting, because it is a bug. > > > If so, Documentation/kmemcheck.txt really needs an update. kmemcheck is different to the slab object lifetime debugger (which is what reported this error). kmemcheck may have turned up in the trace because it was compiled in (and it ties into slab/slub) but wasn't turned on (it can be dynamically toggled via sysfs). kmemcheck keeps a shadow of the memory and via the shadow memory it records whether the memory has been written to yet. I believe kmemcheck's problem is that it can't know when allocated but uninitialised memory is being used on purpose/not really being used (e.g. when gcc does a 32 bit read when only 16 bits have been used but throws the upper 16 bits away). There may be other cases such as when a previously uninitialised buffer is used but the buffer is actually used by an mmaped device... My understanding is that the slab debugger writes poison about the place (e.g. to memory that has been freed and at the start/end of allocations) and then checks to see if someone has scribbled on it. This case is more coarse as it only deals with allocation rather than initialisation (and if you scribble the same value as the poison pattern you go undetected) but I believe this is what Jiri is referring to as a "no false positive possibility" case - it's never right to write to unallocated memory. (fixed up Bob's email address on the cc) -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
