| Message ID | 20180404163445.16492-1-mark.rutland@arm.com |
|---|---|
| State | Accepted |
| Commit | 4d3b57da1593c66835d8e3a757e4751b35493fb8 |
| Headers | show |
| Series | tools: restore READ_ONCE() C++ compatibility | expand |
Hi Mark, On 04/04/2018 10:04 PM, Mark Rutland wrote: > > Zhijian, Sandipan, does this patch work for you? > Yes it does. Thanks for the fix. - Sandipan
On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote: > Hi Mark, > > On 04/04/2018 10:04 PM, Mark Rutland wrote: > > > > Zhijian, Sandipan, does this patch work for you? > > > > Yes it does. Thanks for the fix. Great! Can I take that as a Tested-by? Thanks, Mark.
On 04/04/2018 10:48 PM, Mark Rutland wrote: > On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote: >> Hi Mark, >> >> On 04/04/2018 10:04 PM, Mark Rutland wrote: >>> >>> Zhijian, Sandipan, does this patch work for you? >>> >> >> Yes it does. Thanks for the fix. > > Great! Can I take that as a Tested-by? > Sure. - Sandipan
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? 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.rutland@arm.com> > Fixes: 6aa7de059173a986 ("locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()") > Reported-by: Li Zhijian <lizhijian@cn.fujitsu.com> > Reported-by: Sandipan Das <sandipan@linux.vnet.ibm.com> > Cc: Arnaldo Carvalho de Melo <acme@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 >
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.rutland@arm.com> > > Fixes: 6aa7de059173a986 ("locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()") > > Reported-by: Li Zhijian <lizhijian@cn.fujitsu.com> > > Reported-by: Sandipan Das <sandipan@linux.vnet.ibm.com> > > Cc: Arnaldo Carvalho de Melo <acme@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 > >
On Mon, Apr 09, 2018 at 04:40:32PM -0300, Arnaldo Carvalho de Melo wrote: > 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. Ah, that's great. Sorry for the noise! Mark.
Em Tue, Apr 10, 2018 at 11:55:15AM +0100, Mark Rutland escreveu: > On Mon, Apr 09, 2018 at 04:40:32PM -0300, Arnaldo Carvalho de Melo wrote: > > 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. > Ah, that's great. > Sorry for the noise! No noise at all, your patch is valid and I'm applying it. At some point some code will include compiler.h at some include chain from a C++ file and clang will explode once more, better fix it now :-) - Arnaldo
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
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.rutland@arm.com> Fixes: 6aa7de059173a986 ("locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()") Reported-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reported-by: Sandipan Das <sandipan@linux.vnet.ibm.com> Cc: Arnaldo Carvalho de Melo <acme@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. -- 2.11.0