From: Will Deacon <will.deacon@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Ingo Molnar <mingo@elte.hu>, Davidlohr Bueso <dave@stgolabs.net>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: linux-next: build warnings after merge of the access_once tree
Date: Thu, 26 Mar 2015 17:17:23 +0000 [thread overview]
Message-ID: <20150326171723.GA22620@arm.com> (raw)
In-Reply-To: <20150326170748.GD21418@twins.programming.kicks-ass.net>
On Thu, Mar 26, 2015 at 05:07:48PM +0000, Peter Zijlstra wrote:
> On Thu, Mar 26, 2015 at 09:45:07AM -0700, Linus Torvalds wrote:
>
> > Stop this idiocy.
>
> Yeah, clearly I can type faster than I can think straight :/
>
>
> In any case, I've the below patch; do you want to take it now or do you
> want me to route it through tip/locking/urgent or something like that?
This patch also works fine for me. I managed to get the compiler to split a
64-bit load into 2x32-bit loads using memcpy, so I do like keeping the
8-byte case available for 32-bit architectures than can make use of it.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
> Subject: kernel: Remove atomicy checks from {READ,WRITE}_ONCE
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Thu, 26 Mar 2015 17:45:37 +0100
>
> The fact that volatile allows for atomic load/stores is a special case
> not a requirement for {READ,WRITE}_ONCE(). Their primary purpose is to
> force the compiler to emit load/stores _once_.
>
> So remove the warning as it is correct behaviour. This also implies that
> the u64 case is not 64bit only, so remove the #ifdef so we can generate
> better code in that case.
>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Davidlohr Bueso <dave@stgolabs.net>
> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> include/linux/compiler.h | 16 ----------------
> 1 file changed, 16 deletions(-)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 1b45e4a0519b..0e41ca0e5927 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -192,29 +192,16 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>
> #include <uapi/linux/types.h>
>
> -static __always_inline void data_access_exceeds_word_size(void)
> -#ifdef __compiletime_warning
> -__compiletime_warning("data access exceeds word size and won't be atomic")
> -#endif
> -;
> -
> -static __always_inline void data_access_exceeds_word_size(void)
> -{
> -}
> -
> static __always_inline void __read_once_size(const volatile void *p, void *res, int size)
> {
> switch (size) {
> case 1: *(__u8 *)res = *(volatile __u8 *)p; break;
> case 2: *(__u16 *)res = *(volatile __u16 *)p; break;
> case 4: *(__u32 *)res = *(volatile __u32 *)p; break;
> -#ifdef CONFIG_64BIT
> case 8: *(__u64 *)res = *(volatile __u64 *)p; break;
> -#endif
> default:
> barrier();
> __builtin_memcpy((void *)res, (const void *)p, size);
> - data_access_exceeds_word_size();
> barrier();
> }
> }
> @@ -225,13 +212,10 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
> case 1: *(volatile __u8 *)p = *(__u8 *)res; break;
> case 2: *(volatile __u16 *)p = *(__u16 *)res; break;
> case 4: *(volatile __u32 *)p = *(__u32 *)res; break;
> -#ifdef CONFIG_64BIT
> case 8: *(volatile __u64 *)p = *(__u64 *)res; break;
> -#endif
> default:
> barrier();
> __builtin_memcpy((void *)p, (const void *)res, size);
> - data_access_exceeds_word_size();
> barrier();
> }
> }
>
next prev parent reply other threads:[~2015-03-26 17:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 8:31 linux-next: build warnings after merge of the access_once tree Stephen Rothwell
2015-03-26 10:11 ` Christian Borntraeger
2015-03-26 10:34 ` Peter Zijlstra
2015-03-26 13:27 ` Will Deacon
2015-03-26 14:22 ` Peter Zijlstra
2015-03-26 14:41 ` Will Deacon
2015-03-26 14:51 ` Peter Zijlstra
2015-03-26 15:08 ` Will Deacon
2015-03-26 16:15 ` Linus Torvalds
2015-03-26 16:21 ` Linus Torvalds
2015-03-26 16:36 ` Peter Zijlstra
2015-03-26 16:44 ` Peter Zijlstra
2015-03-26 16:45 ` Peter Zijlstra
[not found] ` <CA+55aFw1WHJqSj+z-mJGY-kxrg_OsGp9jK9VBi+wB4zPgCkv_w@mail.gmail.com>
2015-03-26 17:07 ` Peter Zijlstra
2015-03-26 17:17 ` Will Deacon [this message]
2015-03-26 17:23 ` Christian Borntraeger
2015-03-26 19:42 ` Christian Borntraeger
2015-03-26 16:28 ` Peter Zijlstra
[not found] ` <CA+55aFzUPPSHakwbp-Y-SaXB+o1=V6rOknz7L3AYNXNPU1MSfg@mail.gmail.com>
2015-03-26 17:12 ` Paul E. McKenney
2015-03-26 17:24 ` Christian Borntraeger
2015-03-26 17:52 ` Linus Torvalds
2015-03-26 18:54 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150326171723.GA22620@arm.com \
--to=will.deacon@arm.com \
--cc=borntraeger@de.ibm.com \
--cc=dave@stgolabs.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.