Messages in this thread | | | Date | Tue, 19 Feb 2008 17:52:34 +0200 | From | Pekka Enberg <> | Subject | Re: Linux 2.6.25-rc2 |
| |
Ingo Molnar wrote: > * Pekka Enberg <penberg@cs.helsinki.fi> wrote: > >>> Yes, this can happen. Are you saying it is not safe to be in the >>> lockless path when an IRQ triggers? >> Hmm. The barrier() in slab_free() looks fishy. The comment says it's >> there to make sure we've retrieved c->freelist before c->page but then >> it uses a _compiler barrier_ which doesn't affect the CPU and the >> reads may still be re-ordered... Not sure if that matters here though. > > find a fix patch for that below - most systems affected seem to be SMP > ones. > > If this (or my other patch) indeed solves the problem i'd still favor a > full revert of the SLUB_FASTPATH (commit 1f84260c8ce3b1ce26d4), it looks > quite un-cooked and quite un-tested for multiple independent reasons. > > Sigh, why do i again have to be the messenger who brings the bad news to > SLUB land, and again when poor Christoph went on vacation? :-/ > > Ingo > > --------------------------> > Subject: SLUB: barrier fix > From: Ingo Molnar <mingo@elte.hu> > > --- > mm/slub.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux/mm/slub.c > =================================================================== > --- linux.orig/mm/slub.c > +++ linux/mm/slub.c > @@ -1862,7 +1862,7 @@ static __always_inline void slab_free(st > debug_check_no_locks_freed(object, s->objsize); > do { > freelist = c->freelist; > - barrier(); > + smp_mb(); > /* > * If the compiler would reorder the retrieval of c->page to > * come before c->freelist then an interrupt could
Torsten/Yamin, does this fix things for you? What about reverting commit 1f84260c8ce3b1ce26d4c1d6dedc2f33a3a29c0c ("SLUB: Alternate fast paths using cmpxchg_local")?
Pekka
| |