Re: [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb_alloc)

[Frederic Weisbecker]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/