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 <[email protected]>
>> ---
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
