lkml.org 
[lkml]   [2008]   [Feb]   [20]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
Messages in this thread
    /
    SubjectRe: Linux 2.6.25-rc2
    From"Zhang, Yanmin" <>
    DateWed, 20 Feb 2008 14:53:10 +0800
    On Wed, 2008-02-20 at 10:08 +0800, Zhang, Yanmin wrote:
    > On Wed, 2008-02-20 at 08:36 +0800, Zhang, Yanmin wrote:
    > > On Tue, 2008-02-19 at 17:52 +0200, Pekka Enberg wrote:
    > > > 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")?
    > > I'm busy in another issue and will test it ASAP. Sorry.
    > I tested it on my 3 x86-64 machines. The small fix to use smp_mb to replace
    > barrier in slab_free doesn't work. Kernel still crashed at the same place.
    > 
    > I will test the reverting patch.
    Kernel with the reverting patch is ok.
    I ran reboot/hackbench for more than 10 times on every one of my 3 x86-64 machines,
    and kernel didn't crash.
    
    -yanmin
    
    
    --
    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/
    
    
    \
     
     \ /
      Last update: 2008-02-20 06:57    [from the cache]
    ©2003-2008