Re: 2.6.21.3 Oops (was Re: XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b00bd)

["Marco Berizzi" <pupilla@hotmail.com>]

Christoph Lameter wrote:

> On Thu, 21 Jun 2007, Marco Berizzi wrote:
>
> > > > Some RCU callback (that calls kmem_cache_free()) oopsed and
> > > > panic'ed his box. [ Marco had experienced fs issues lately, so
we
> > > could
> > > > suspect file_free_rcu() here, but I can't really tell from the
stack
> > > trace;
> > > > BTW whats with the rampant disease in the kernel to declare as
> > inline
> > > > even those functions exclusively meant to be dereferenced and
passed
> > > > as pointers to call_rcu()?! ]
>
>
> The BUG_ON that triggers this signals us that someone tried to perform
> a kfree or kmem_cache_free on an object that is not in a slab page.
>
>
> > Hello everybody.
> > Few minutes ago 2.6.22-rc5 has been
> > crashed with this error (see also the
> > bitmap at http://80.204.235.230/foto2.jpg).
> > Just for record: if I build linux
> > with 'Debug slab memory allocations'
> > the box doesn't crash.
>
> Hmmm.. That is strange and could point to some sort of race condition.
>
> 1. The object is freed. It is the last page on the slab. Thus slab
> decommissions the page and resets PageSlab.
>
> 2. Another process tries to free the object again. Now the page is no
> longer marked as being a SLAB page. Thus the BUG_ON is triggered.
>
> Can you try the same with SLUB? Boot with "slub_debug".

With the same kernel or should I compile with
some other options?

> If you cannot
> trigger the error anymore do limited debugging by booting with
> "slub_debug=F". Maybe that will be enough to trigger the race.