Re: [PATCH] compiler.h: cast away attributes in WRITE_ONCE magic

[Christian Borntraeger <borntraeger@de.ibm.com>]

Am 04.08.2015 um 11:20 schrieb Peter Zijlstra:
> On Tue, Aug 04, 2015 at 09:55:48AM +0200, Christian Borntraeger wrote:
>> kernel build bot showed a warning triggered by commit
>> 76695af20c01 ("locking, arch: use WRITE_ONCE()/READ_ONCE() in
>> smp_store_release()/smp_load_acquire()"). Turns out that sparse
>> does not like WRITE_ONCE accessing elements from the (sparse)
>> rcu address space.
>>
>> fs/afs/inode.c:448:9: sparse: incorrect type in initializer (different address spaces)
>> fs/afs/inode.c:448:9:    expected struct afs_permits *__val
>> fs/afs/inode.c:448:9:    got void [noderef] <asn:4>*<noident>
>>
>> Solution is to force cast away the sparse attributes for the initializer
>> of the union in WRITE_SAME. As this now gets too long, lets split
> 
> WRITE_ONCE, right?

Indeed, guess what area I was looking into before....;-)

Shall I respin or can you fixup.


> 
>> the macro.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  include/linux/compiler.h | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> index e08a6ae..c836eb2 100644
>> --- a/include/linux/compiler.h
>> +++ b/include/linux/compiler.h
>> @@ -252,7 +252,12 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
>>  	({ union { typeof(x) __val; char __c[1]; } __u; __read_once_size(&(x), __u.__c, sizeof(x)); __u.__val; })
>>  
>>  #define WRITE_ONCE(x, val) \
>> -	({ union { typeof(x) __val; char __c[1]; } __u = { .__val = (val) }; __write_once_size(&(x), __u.__c, sizeof(x)); __u.__val; })
>> +({							\
>> +	union { typeof(x) __val; char __c[1]; } __u =	\
>> +		{ .__val = (__force typeof(x)) (val) }; \
>> +	__write_once_size(&(x), __u.__c, sizeof(x));	\
>> +	__u.__val;					\
>> +})
> 
> Thanks!
> 
> READ_ONCE() doesn't have a similar problem because it only has the one
> input type, which automagically becomes the output type, right?

Good question. The assigment that failed was the initialization of the temporary union,
which was introduced to handle const pointers. READ_ONCE does not have such assignment
so this thing should be safe. I cant say right now if the macro return value causes
issues somewhere else, e.g. does code want to have values __rcu tagged?

I have checked some of the kbuild output and all new things seem to be fixed so this
patch itself is probably an improvement (pending kbuild coverage). 

Having a testcase that works with ACCESS_ONCE but fails with READ_ONCE would be a good
start to see if we need to change READ_ONCE further.

Christian