On Sun, Feb 22, 2009 at 08:18:22PM +0000, Sitsofe Wheeler wrote: > 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). Ah sorry, I thought it was a kmemcheck warning. That's why I didn't understand what Jiri said to me. > 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... Ok. > 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) Well I understand better now. Thanks for the explanations. > -- > 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
