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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
