Messages in this thread | | | Date | Thu, 13 Jul 2006 00:44:45 -0700 | From | Andrew Morton <> | Subject | Re: Random panics seen in 2.6.18-rc1 |
| |
On Thu, 13 Jul 2006 09:26:35 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > > > But what was that change _for_? Presumably, to plug some lockdep > > problem. Which now will come back. > > correct - but i first wanted to get the fix out, before trying to fix > the lockdep thing.
More yup.
> > And the additional arg to __cache_free() was rather a step backwards - > > this is fastpath. With a bit more effort that could have been avoided > > (please). > > yeah, i'll fix this. Any suggestions of how to avoid the parameter > passing? (without ugly #ifdeffery)
No, I don't see a way apart from inlining __cache_free(), or inlining cache_free_alien() into both kfree() and kmem_cache_free(), both of which are unattractive.
Well. One could do
local_irq_disable(); cachep->array[smp_processor_id()]->lockdep_nested = 1; __cache_free(...) cachep->array[smp_processor_id()]->lockdep_nested = 0; local_irq_enable();
then do lots of ifdeffery to make that go away if !LOCKDEP. But sheesh. - 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/
| |