Re: yet more slab corruption.

[Andreas Gruenbacher <agruen@suse.de>]

On Wednesday, 08 March 2006 08:14, Andrew Morton wrote:
> Dave Jones <davej@redhat.com> wrote:
> > Garg. Is there no end to these ?
> > That kernel is based off 2.6.16rc5-git8
> >
> > This brings the current count up to 8 different patterns filed
> > against our 2.6.16rc tree in Fedora bugzilla.
> > (One of them doesn't count as it's against the out-of-tree bcm43xx
> > driver).

We have two similar bug reports to 
https://bugzilla.redhat.com/bugzilla/184310, slab corruption in an object 
freed by release_mem:

	https://bugzilla.novell.com/151111 (i386)
	https://bugzilla.novell.com/154601 (x86_64)

So this bug seems to trigger on different architectures, and with different 
hardware.

> A use-after-free on size-2048.  We wrote -1L and 0L apparently 0x6b8 bytes
> into the object.  That's an awfully large offset for tty_struct - off the
> end.  Sometimes the buffer was used as skb data too.

I don't know about offset 0x6b8: 0x6b is POISON_FREE in mm/slab.c, so this is 
probably a misread. I think the correct offset is 0xbc. Bug 151111 has the 
corruption at the same offset. On x86_64, the offset is 0x124. This seems to 
be tty_struct->winsize in all cases, even though I can't tell for sure for 
most of the reports anymore.

So this could be a tty_struct locking bug -- it's surprising that we are also 
seeing filesystem corruption, but only in some cases. There was a recent 
locking fix in this area by Paul Fulghum <paulkf@microgate.com> from Feb 15 
which might be related, but the fix looks good to me: 
http://www.kernel.org/hg/linux-2.6/?cs=623e3c38a511.

> Unless it was a DMA scribble, CONFIG_DEBUG_PAGEALLOC should catch this.

This didn't trigger anything in an overnight run. Any further ideas?

Thanks,
Andreas

-- 
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs