From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Will Deacon <will.deacon@arm.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>,
"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Davidlohr Bueso <dave@stgolabs.net>,
Paul McKenney <paulmck@linux.vnet.ibm.com>
Subject: Re: linux-next: build warnings after merge of the access_once tree
Date: Thu, 26 Mar 2015 17:45:37 +0100 [thread overview]
Message-ID: <20150326164537.GI24151@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20150326164441.GH24151@twins.programming.kicks-ass.net>
On Thu, Mar 26, 2015 at 05:44:42PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 26, 2015 at 05:36:47PM +0100, Peter Zijlstra wrote:
> > Can't we make an argument that these barrier calls are not required? The
> > memcpy() call already guarantees we emit the loads and its opaque so the
> > compiler cannot 'cache' the value. So I see not immediate reason for the
> > dual memory clobber.
>
> Oh wait, it needs to reassess the content of the target variable after
> the memcpy of course.
>
> Could we then at least make the 64bit case unconditional as well?
Like so.
---
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 16:45 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 [this message]
[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
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=20150326164537.GI24151@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--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=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
/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.