Re: .17rc5 cfq slab corruption.

[Dave Jones <davej@redhat.com>]

On Tue, May 30, 2006 at 09:52:24AM -0400, Dave Jones wrote:
 > On Tue, May 30, 2006 at 03:50:59PM +0200, Jens Axboe wrote:
 > 
 >  > >  > >  > Pretty baffling... cfq has been hammered pretty thoroughly over the
 >  > >  > >  > last months and _nothing_ has shown up except some performance anomalies
 >  > >  > >  > that are now fixed. Since daves case (at least) seems to be
 >  > >  > >  > use-after-free, I'll see if I can reproduce with some contrived case.
 >  > >  > >  > I'm asuming that picasa forks and exits a lot with submitted io in
 >  > >  > >  > between than may not have finished at exit.
 >  > >  > > 
 >  > >  > > The second time I hit it, was actually during boot up.
 >  > >  > 
 >  > >  > Dave, do you have any io scheduler switching going on?
 >  > > 
 >  > > Nope, everything set to use CFQ as default, and left that way.
 >  > 
 >  > Hrmpf ok, I had hoped perhaps something in your init scripts modified
 >  > the scheduler value.
 > 
 > grep doesn't show anything in init scripts, and ttbomk, hald isn't messing
 > with this. (Actually I'm seeing it trigger before that gets started
 > anyway, so that can't be it).

In case it makes a difference to help with reproducing -- the hardware of this
system is:

two sata drives sda1/sdb1 in single-volume device-mapper configuration as VolGroup00-LogVol00
pata cd drive on /dev/hdc
usb memory stick on sdc1

Nothing too out of the ordinary there..

		Dave

-- 
http://www.codemonkey.org.uk