[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <200710261209.58519.nickpiggin@yahoo.com.au>
Date: Fri, 26 Oct 2007 12:09:58 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
paulus@...ba.org, benh@...nel.crashing.org, shaggy@...tin.ibm.com,
adaplas@...il.com, "Morton, Andrew" <akpm@...ux-foundation.org>,
xfs-masters@....sgi.com
Subject: [interesting] smattering of possible memory ordering bugs
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. Lot
of work. But forget that...
Some surprises with more obvious bugs, which I have added some cc's for.
powerpc seems to have an mmu context allocation bug, (and possible
improvement in hpte locking with the new bitops).
floppy is using a crazy open coded bit mutex, convert to regular mutex.
vt has something strange too.
fs-writeback could be made a little safer by properly closing the "critical"
section (the existing sections aren't really critical, but you never know
what the future holds ;))
jfs seems to be missing an obvious smp_mb__before_clear_bit (and a less
obvious smp_mb__after_clear_bit)
xfs seems to be missing smp_mb__before
Lots of code that allocates things (eg. msi interrupts) is suspicious. I'm
not exactly sure if these allocation bitmaps are actually used to protect
data structures or not...
I'll have to get round to preparing proper patches for these things if I
don't hear nacks...
View attachment "bitops-fixups.patch" of type "text/x-diff" (24409 bytes)
Powered by blists - more mailing lists