From: Peter Zijlstra <peterz@infradead.org>
To: Will Deacon <will@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Daniel Axtens <dja@axtens.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Christophe Leroy <christophe.leroy@c-s.fr>,
linux-arch <linux-arch@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Segher Boessenkool <segher@kernel.crashing.org>,
Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))
Date: Mon, 16 Dec 2019 12:47:24 +0100 [thread overview]
Message-ID: <20191216114724.GL2844@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191213144359.GA3826@willie-the-truck>
On Mon, Dec 16, 2019 at 10:28:06AM +0000, Will Deacon wrote:
> However, enabling this for 32-bit ARM is total carnage; as Linus mentioned,
> a whole bunch of code appears to be relying on atomic 64-bit access of
> READ_ONCE(); the perf ring buffer, io_uring, the scheduler, pm_runtime,
> cpuidle, ... :(
>
> Unfortunately, at least some of these *do* look like bugs, but I can't see
> how we can fix them, not least because the first two are user ABI afaict. It
> may also be that in practice we get 2x32-bit stores, and that works out fine
> when storing a 32-bit virtual address. I'm not sure what (if anything) the
> compiler guarantees in these cases.
Perf does indeed have a (known) problem here for the head/tail values.
Last time we looked at that nobody could really come up with a sane
solution that wouldn't break something.
I'll try and dig out that thread. Perhaps casting the value to 'unsigned
long' internally might work, I forgot the details.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Will Deacon <will@kernel.org>
Cc: linux-arch <linux-arch@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Mark Rutland <mark.rutland@arm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Daniel Axtens <dja@axtens.net>
Subject: Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))
Date: Mon, 16 Dec 2019 12:47:24 +0100 [thread overview]
Message-ID: <20191216114724.GL2844@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191213144359.GA3826@willie-the-truck>
On Mon, Dec 16, 2019 at 10:28:06AM +0000, Will Deacon wrote:
> However, enabling this for 32-bit ARM is total carnage; as Linus mentioned,
> a whole bunch of code appears to be relying on atomic 64-bit access of
> READ_ONCE(); the perf ring buffer, io_uring, the scheduler, pm_runtime,
> cpuidle, ... :(
>
> Unfortunately, at least some of these *do* look like bugs, but I can't see
> how we can fix them, not least because the first two are user ABI afaict. It
> may also be that in practice we get 2x32-bit stores, and that works out fine
> when storing a 32-bit virtual address. I'm not sure what (if anything) the
> compiler guarantees in these cases.
Perf does indeed have a (known) problem here for the head/tail values.
Last time we looked at that nobody could really come up with a sane
solution that wouldn't break something.
I'll try and dig out that thread. Perhaps casting the value to 'unsigned
long' internally might work, I forgot the details.
next prev parent reply other threads:[~2019-12-16 11:47 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-06 12:46 [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops) Michael Ellerman
2019-12-06 12:46 ` Michael Ellerman
2019-12-06 13:16 ` Peter Zijlstra
2019-12-06 13:16 ` Peter Zijlstra
2019-12-10 5:38 ` Michael Ellerman
2019-12-10 5:38 ` Michael Ellerman
2019-12-10 10:15 ` Peter Zijlstra
2019-12-10 10:15 ` Peter Zijlstra
2019-12-11 0:29 ` Michael Ellerman
2019-12-11 0:29 ` Michael Ellerman
2019-12-12 5:42 ` READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops)) Michael Ellerman
2019-12-12 5:42 ` Michael Ellerman
2019-12-12 8:01 ` Peter Zijlstra
2019-12-12 8:01 ` Peter Zijlstra
2019-12-12 10:07 ` Will Deacon
2019-12-12 10:07 ` Will Deacon
2019-12-12 10:46 ` Peter Zijlstra
2019-12-12 10:46 ` Peter Zijlstra
2019-12-12 17:04 ` Will Deacon
2019-12-12 17:04 ` Will Deacon
2019-12-12 17:16 ` Will Deacon
2019-12-12 17:16 ` Will Deacon
2019-12-12 17:41 ` Linus Torvalds
2019-12-12 17:41 ` Linus Torvalds
2019-12-12 17:50 ` Segher Boessenkool
2019-12-12 17:50 ` Segher Boessenkool
2019-12-12 18:06 ` Will Deacon
2019-12-12 18:06 ` Will Deacon
2019-12-12 18:29 ` Christian Borntraeger
2019-12-12 18:29 ` Christian Borntraeger
2019-12-12 18:43 ` Linus Torvalds
2019-12-12 18:43 ` Linus Torvalds
2019-12-12 19:34 ` Will Deacon
2019-12-12 19:34 ` Will Deacon
2019-12-12 20:21 ` Peter Zijlstra
2019-12-12 20:21 ` Peter Zijlstra
2019-12-12 20:53 ` Peter Zijlstra
2019-12-12 20:53 ` Peter Zijlstra
2019-12-13 10:47 ` Luc Van Oostenryck
2019-12-13 10:47 ` Luc Van Oostenryck
2019-12-13 12:56 ` Peter Zijlstra
2019-12-13 12:56 ` Peter Zijlstra
2019-12-13 14:28 ` Luc Van Oostenryck
2019-12-13 14:28 ` Luc Van Oostenryck
2019-12-12 20:49 ` Linus Torvalds
2019-12-12 20:49 ` Linus Torvalds
2019-12-13 13:17 ` Arnd Bergmann
2019-12-13 13:17 ` Arnd Bergmann
2019-12-13 21:32 ` Arnd Bergmann
2019-12-13 21:32 ` Arnd Bergmann
2019-12-13 22:01 ` Linus Torvalds
2019-12-13 22:01 ` Linus Torvalds
2019-12-16 10:28 ` Will Deacon
2019-12-16 10:28 ` Will Deacon
2019-12-16 11:47 ` Peter Zijlstra [this message]
2019-12-16 11:47 ` Peter Zijlstra
2019-12-16 12:06 ` Arnd Bergmann
2019-12-16 12:06 ` Arnd Bergmann
2019-12-17 17:07 ` Will Deacon
2019-12-17 17:07 ` Will Deacon
2019-12-17 18:04 ` Linus Torvalds
2019-12-17 18:04 ` Linus Torvalds
2019-12-17 18:05 ` Linus Torvalds
2019-12-17 18:05 ` Linus Torvalds
2019-12-17 18:31 ` Will Deacon
2019-12-17 18:31 ` Will Deacon
2019-12-17 18:32 ` Linus Torvalds
2019-12-17 18:32 ` Linus Torvalds
2019-12-18 12:17 ` Michael Ellerman
2019-12-18 12:17 ` Michael Ellerman
2019-12-19 12:11 ` Will Deacon
2019-12-19 12:11 ` Will Deacon
2019-12-18 10:22 ` Christian Borntraeger
2019-12-18 10:22 ` Christian Borntraeger
2019-12-18 10:35 ` Will Deacon
2019-12-18 10:35 ` Will Deacon
2019-12-13 12:07 ` Michael Ellerman
2019-12-13 12:07 ` Michael Ellerman
2019-12-13 13:53 ` Segher Boessenkool
2019-12-13 13:53 ` Segher Boessenkool
2019-12-13 21:06 ` Michael Ellerman
2019-12-13 21:06 ` Michael Ellerman
2019-12-12 15:10 ` Segher Boessenkool
2019-12-12 15:10 ` Segher Boessenkool
2019-12-06 22:15 ` [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops) pr-tracker-bot
2019-12-06 22:15 ` pr-tracker-bot
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=20191216114724.GL2844@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=arnd@arndb.de \
--cc=borntraeger@de.ibm.com \
--cc=christophe.leroy@c-s.fr \
--cc=dja@axtens.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=mpe@ellerman.id.au \
--cc=segher@kernel.crashing.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.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.