On Tue, Jun 03, 2014 at 05:09:08PM +0200, Peter Zijlstra wrote: > 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). Maybe at some point sparse needs to keep a bit mask for the address spaces, so that you caould say somthing like: struct foo __atomic __rcu *p; Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
