Messages in this thread | | | From | "Marco Berizzi" <> | Subject | 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) | Date | Fri, 22 Jun 2007 11:22:09 +0200 |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |