From: Peter Zijlstra <peterz@infradead.org>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
kasan-dev <kasan-dev@googlegroups.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Networking <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-media@vger.kernel.org,
linux-wireless <linux-wireless@vger.kernel.org>,
kernel-build-reports@lists.linaro.org,
"David S . Miller" <davem@davemloft.net>,
Paul McKenney <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE
Date: Fri, 3 Mar 2017 15:49:38 +0100 [thread overview]
Message-ID: <20170303144938.GF6557@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <f86cf852-3960-0dcf-5917-509080ca7bf5@de.ibm.com>
On Fri, Mar 03, 2017 at 09:26:50AM +0100, Christian Borntraeger wrote:
> Right. The main purpose is to read/write _ONCE_. You can assume a somewhat
> atomic access for sizes <= word size. And there are certainly places that
> rely on that. But the *ONCE thing is mostly used for things where we used
> barrier() 10 years ago.
A lot of code relies on READ/WRITE_ONCE() to generate single
instructions for naturally aligned machined word sized loads/stores
(something GCC used to guarantee, but does no longer IIRC).
So much so that I would say its a bug if READ/WRITE_ONCE() doesn't
generate a single instruction under those conditions.
However, every time I've tried to introduce stricter
semantics/primitives to verify things Linus hated it.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Christian Borntraeger
<borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
kasan-dev <kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
Andrey Ryabinin
<aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>,
Alexander Potapenko
<glider-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Dmitry Vyukov <dvyukov-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Networking <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
kernel-build-reports-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
"David S . Miller"
<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
Paul McKenney
<paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE
Date: Fri, 3 Mar 2017 15:49:38 +0100 [thread overview]
Message-ID: <20170303144938.GF6557@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <f86cf852-3960-0dcf-5917-509080ca7bf5-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
On Fri, Mar 03, 2017 at 09:26:50AM +0100, Christian Borntraeger wrote:
> Right. The main purpose is to read/write _ONCE_. You can assume a somewhat
> atomic access for sizes <= word size. And there are certainly places that
> rely on that. But the *ONCE thing is mostly used for things where we used
> barrier() 10 years ago.
A lot of code relies on READ/WRITE_ONCE() to generate single
instructions for naturally aligned machined word sized loads/stores
(something GCC used to guarantee, but does no longer IIRC).
So much so that I would say its a bug if READ/WRITE_ONCE() doesn't
generate a single instruction under those conditions.
However, every time I've tried to introduce stricter
semantics/primitives to verify things Linus hated it.
next prev parent reply other threads:[~2017-03-03 15:48 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-02 16:38 [PATCH 00/26] bring back stack frame warning with KASAN Arnd Bergmann
2017-03-02 16:38 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 01/26] compiler: introduce noinline_for_kasan annotation Arnd Bergmann
2017-03-03 13:50 ` Andrey Ryabinin
2017-03-03 13:55 ` Alexander Potapenko
2017-03-03 13:55 ` Alexander Potapenko
2017-03-03 14:30 ` Arnd Bergmann
2017-03-03 14:33 ` Alexander Potapenko
2017-03-03 14:33 ` Alexander Potapenko
2017-03-03 14:51 ` Arnd Bergmann
2017-03-03 16:34 ` David Laight
2017-03-02 16:38 ` [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE Arnd Bergmann
2017-03-02 16:51 ` Christian Borntraeger
2017-03-02 17:55 ` Arnd Bergmann
2017-03-02 19:00 ` Christian Borntraeger
2017-03-02 21:45 ` Arnd Bergmann
2017-03-03 8:26 ` Christian Borntraeger
2017-03-03 8:26 ` Christian Borntraeger
2017-03-03 9:54 ` Arnd Bergmann
2017-03-03 9:54 ` Arnd Bergmann
2017-03-03 14:49 ` Peter Zijlstra [this message]
2017-03-03 14:49 ` Peter Zijlstra
2017-03-03 14:57 ` Peter Zijlstra
2017-03-02 16:38 ` [PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro Arnd Bergmann
2017-03-02 16:38 ` [PATCH 04/26] tty: kbd: reduce stack size with KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan Arnd Bergmann
2017-03-02 16:38 ` [PATCH 06/26] rocker: mark rocker_tlv_put_* functions as noinline_for_kasan Arnd Bergmann
2017-03-02 16:38 ` [PATCH 07/26] brcmsmac: reduce stack size with KASAN Arnd Bergmann
2017-03-06 9:16 ` Arend Van Spriel
2017-03-06 10:38 ` Arnd Bergmann
2017-03-06 11:02 ` Arend Van Spriel
2017-03-06 11:16 ` Arnd Bergmann
2017-03-06 11:18 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size Arnd Bergmann
2017-03-06 9:30 ` Arend Van Spriel
2017-03-06 9:30 ` Arend Van Spriel
2017-03-06 16:19 ` Kalle Valo
2017-03-06 21:34 ` Arnd Bergmann
2017-03-06 21:34 ` Arnd Bergmann
2017-03-07 9:44 ` Kalle Valo
2017-03-07 9:55 ` Arend Van Spriel
2017-03-02 16:38 ` [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy Arnd Bergmann
2017-03-06 9:31 ` Arend Van Spriel
2017-03-02 16:38 ` [PATCH 10/26] brcmsmac: reindent split functions Arnd Bergmann
2017-03-06 9:33 ` Arend Van Spriel
2017-03-06 16:24 ` Kalle Valo
2017-03-02 16:38 ` [PATCH 11/26] rtlwifi: reduce stack usage for KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 12/26] wl3501_cs: reduce stack size " Arnd Bergmann
2017-03-02 16:38 ` [PATCH 13/26] rtl8180: " Arnd Bergmann
2017-03-02 16:38 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 14/26] [media] dvb-frontends: reduce stack size in i2c access Arnd Bergmann
2017-03-02 16:38 ` [PATCH 15/26] [media] tuners: i2c: reduce stack usage for tuner_i2c_xfer_* Arnd Bergmann
2017-03-02 16:38 ` [PATCH 16/26] [media] i2c: adv7604: mark register access as noinline_for_kasan Arnd Bergmann
2017-03-02 16:38 ` [PATCH 17/26] [media] i2c: ks0127: reduce stack frame size for KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 18/26] [media] i2c: cx25840: avoid stack overflow with KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 19/26] [media] r820t: mark register functions as noinline_for_kasan Arnd Bergmann
2017-03-02 16:38 ` [PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce stack size Arnd Bergmann
2017-04-17 17:07 ` Mauro Carvalho Chehab
2017-03-02 16:38 ` [PATCH 21/26] drm/bridge: ps8622: reduce stack size for KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 23/26] mtd: cfi: reduce stack size " Arnd Bergmann
2017-03-02 16:38 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 24/26] ocfs2: " Arnd Bergmann
2017-03-02 17:46 ` Joe Perches
2017-03-02 22:22 ` Arnd Bergmann
2017-03-02 22:40 ` Joe Perches
2017-03-02 22:40 ` Joe Perches
2017-03-02 22:59 ` Arnd Bergmann
2017-03-02 23:58 ` Joe Perches
2017-03-02 16:38 ` [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan Arnd Bergmann
2017-03-03 14:20 ` Andrey Ryabinin
2017-03-03 14:54 ` Arnd Bergmann
2017-03-03 15:22 ` Andrey Ryabinin
2017-03-03 15:37 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 26/26] kasan: rework Kconfig settings Arnd Bergmann
2017-03-03 14:51 ` Andrey Ryabinin
2017-03-03 15:03 ` Arnd Bergmann
2017-03-03 12:25 ` [PATCH 00/26] bring back stack frame warning with KASAN Alexander Potapenko
2017-03-03 12:25 ` Alexander Potapenko
2017-03-03 12:54 ` Arnd Bergmann
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=20170303144938.GF6557@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=borntraeger@de.ibm.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kernel-build-reports@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.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.