On Tue, 2008-02-19 at 17:52 +0200, Pekka Enberg wrote:
> Ingo Molnar wrote:
> > * Pekka Enberg <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> >
> > ---
> > 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")?
I'm busy in another issue and will test it ASAP. Sorry.
-yanmin
--
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/
