Re: [interesting] smattering of possible memory ordering bugs

2007-10-26 Thread Dave Kleikamp
Memory barriers aren't one of my strengths, but this appears correct. Acked-by: Dave Kleikamp <[EMAIL PROTECTED]> On Fri, 2007-10-26 at 12:09 +1000, Nick Piggin wrote: > Index: linux-2.6/fs/jfs/jfs_metapage.c > === > ---

Re: [interesting] smattering of possible memory ordering bugs

2007-10-26 Thread Dave Kleikamp
Memory barriers aren't one of my strengths, but this appears correct. Acked-by: Dave Kleikamp [EMAIL PROTECTED] On Fri, 2007-10-26 at 12:09 +1000, Nick Piggin wrote: Index: linux-2.6/fs/jfs/jfs_metapage.c === ---

Re: [interesting] smattering of possible memory ordering bugs

2007-10-25 Thread Benjamin Herrenschmidt
On Fri, 2007-10-26 at 13:47 +1000, Nick Piggin wrote: > I don't think the previous code was wrong... it's not a locked section > > and we don't care about ordering previous stores. It's an > allocation, it > > should be fine. In general, bitmap allocators should be allright. > > Well if it is

Re: [interesting] smattering of possible memory ordering bugs

2007-10-25 Thread Nick Piggin
On Friday 26 October 2007 13:35, Benjamin Herrenschmidt wrote: [acks] Thanks for those... > > Index: linux-2.6/include/asm-powerpc/mmu_context.h > > === > > --- linux-2.6.orig/include/asm-powerpc/mmu_context.h > > +++

Re: [interesting] smattering of possible memory ordering bugs

2007-10-25 Thread Benjamin Herrenschmidt
> Index: linux-2.6/arch/powerpc/mm/hash_native_64.c > === > --- linux-2.6.orig/arch/powerpc/mm/hash_native_64.c > +++ linux-2.6/arch/powerpc/mm/hash_native_64.c > @@ -113,7 +113,7 @@ static inline void native_lock_hpte(stru >

[interesting] smattering of possible memory ordering bugs

2007-10-25 Thread Nick Piggin
Hi, Just out of interest, I did a grep for files containing test_and_set_bit as well as clear_bit (excluding obvious ones like include/asm-*/bitops.h). Quite a few interesting things. There is a lot of stuff in drivers/* that could be suspect, WRT memory barriers, including lots I didn't touch.

[interesting] smattering of possible memory ordering bugs

2007-10-25 Thread Nick Piggin
Hi, Just out of interest, I did a grep for files containing test_and_set_bit as well as clear_bit (excluding obvious ones like include/asm-*/bitops.h). Quite a few interesting things. There is a lot of stuff in drivers/* that could be suspect, WRT memory barriers, including lots I didn't touch.

Re: [interesting] smattering of possible memory ordering bugs

2007-10-25 Thread Benjamin Herrenschmidt
Index: linux-2.6/arch/powerpc/mm/hash_native_64.c === --- linux-2.6.orig/arch/powerpc/mm/hash_native_64.c +++ linux-2.6/arch/powerpc/mm/hash_native_64.c @@ -113,7 +113,7 @@ static inline void native_lock_hpte(stru

Re: [interesting] smattering of possible memory ordering bugs

2007-10-25 Thread Nick Piggin
On Friday 26 October 2007 13:35, Benjamin Herrenschmidt wrote: [acks] Thanks for those... Index: linux-2.6/include/asm-powerpc/mmu_context.h === --- linux-2.6.orig/include/asm-powerpc/mmu_context.h +++

Re: [interesting] smattering of possible memory ordering bugs

2007-10-25 Thread Benjamin Herrenschmidt
On Fri, 2007-10-26 at 13:47 +1000, Nick Piggin wrote: I don't think the previous code was wrong... it's not a locked section and we don't care about ordering previous stores. It's an allocation, it should be fine. In general, bitmap allocators should be allright. Well if it is just