Em Mon, Apr 09, 2018 at 06:10:41PM +0100, Mark Rutland escreveu: > Hi Arnaldo, > > As Sandipan gave a Tested-by for this, are you happy to pick it up as a > fix for v4.17? > > Or would you prefer that I resend this?
I forgot about this fix, but was exposed to it while processing Sandipan's patches for fixing up builtin clang support, so I ended up adding the following patch: https://git.kernel.org/acme/c/ad0902e0c400 This sidesteps this issue by removing the sequence of includes that ends up including the compiler.h from a C++ file. Now 'make LIBCLANGLLVM=1 -C tools/perf' works, but I'll look at the patch below, probably it will save some time in the future if we get to include compiler.h from C++ code again... Take a look at my perf/urgent branch, that I just asked Ingo to pull. - Arnaldo > Thanks, > Mark. > > On Wed, Apr 04, 2018 at 05:34:45PM +0100, Mark Rutland wrote: > > Our userspace <linux/compiler.h> defines READ_ONCE() in a way that clang > > doesn't like, as we have an anonymous union in which neither field is > > initialized. > > > > WRITE_ONCE() is fine since it initializes the __val field. For > > READ_ONCE() we can keep clang and GCC happy with a dummy initialization > > of the __c field, so let's do that. > > > > At the same time, let's split READ_ONCE() and WRITE_ONCE() over several > > lines for legibility, as we do in the in-kernel <linux/compiler.h>. > > > > Signed-off-by: Mark Rutland <mark.rutl...@arm.com> > > Fixes: 6aa7de059173a986 ("locking/atomics: COCCINELLE/treewide: Convert > > trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()") > > Reported-by: Li Zhijian <lizhij...@cn.fujitsu.com> > > Reported-by: Sandipan Das <sandi...@linux.vnet.ibm.com> > > Cc: Arnaldo Carvalho de Melo <a...@redhat.com> > > --- > > tools/include/linux/compiler.h | 20 +++++++++++++++----- > > 1 file changed, 15 insertions(+), 5 deletions(-) > > > > Hi, > > > > This is fallout from my automated ACCESS_ONCE() removal, and I'm not that > > familiar with using clang for perf. > > > > In local testing, this fixes READ_ONCE() when compiling with clang, but I > > subsequently hit some other issues which I believe are down to LLVM API > > changes. > > > > Zhijian, Sandipan, does this patch work for you? > > > > Thanks, > > Mark. > > > > diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h > > index 04e32f965ad7..1827c2f973f9 100644 > > --- a/tools/include/linux/compiler.h > > +++ b/tools/include/linux/compiler.h > > @@ -151,11 +151,21 @@ static __always_inline void > > __write_once_size(volatile void *p, void *res, int s > > * required ordering. > > */ > > > > -#define READ_ONCE(x) \ > > - ({ 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; }) > > +#define READ_ONCE(x) \ > > +({ \ > > + union { typeof(x) __val; char __c[1]; } __u = \ > > + { .__c = { 0 } }; \ > > + __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; \ > > +}) > > > > > > #ifndef __fallthrough > > -- > > 2.11.0 > >
