On Tue, Jun 03, 2014 at 07:07:27AM -0700, Paul E. McKenney wrote: > On Tue, Jun 03, 2014 at 09:36:13AM +0200, Peter Zijlstra wrote: > > > > #ifdef __CHECKER__ > > #define __atomic __attribute__((address_space(5))) > > #else > > #define __atomic > > #endif > > > > #define store(p, v) (*(p) = (typeof(*(p)) __force __atomic)(v)) > > #define load(p) ((typeof(*p) __force)ACCESS_ONCE(*(p))) > > > > Along with changes to xchg() and cmpxchg() that require them to take > > pointers to __atomic. > > > > That way we keep the flexibility of xchg() and cmpxchg() for being > > (mostly) type and size invariant, and get sparse to find wrong usage. > > > > Then parisc, sparc32, tile32, metag-lock1 and arc-!llsc can go implement > > store() however they like. > > Should be fun interacting with atomic operations on __rcu variables > (address space 4). Of course, that is already fun... > Hmm, good point, I suppose sparse doesn't like two different address_space annotations on the same variable ? /me adds Christpoher Li to the CC list. ISTR Mikulas actually listing one such, me digs in recent email.. > $ grep -w "fdt->fd" */*.c > fs/file.c: free_fdmem(fdt->fd); > fs/file.c: fdt->fd = data; > fs/file.c: free_fdmem(fdt->fd); > fs/file.c: struct file * file = xchg(&fdt->fd[i], NULL); So yes, that's going to be fun, mostly because rcu_assign_pointer() doesn't actually do the right magic for this to be safe on their platform(s).
Attachment:
pgpci_v4X4TIP.pgp
Description: PGP signature
