Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 3 Oct 2017 10:27:42 -0700 | Subject | Re: [GIT PULL] percpu fixes for v4.14-rc3 |
| |
On Tue, Oct 3, 2017 at 6:26 AM, Tejun Heo <tj@kernel.org> wrote: > > * Mark noticed that the generic implementations of percpu local atomic > reads aren't properly protected against irqs and there's a (slim) > chance for split reads on some 32bit systems.
Grr.
Do we really want to support 64-bit percpu operations on 32-bit architectures?
It does kind of break the whole point of percpu operations, and I would like to point out that I find things like
static DEFINE_PER_CPU(u64, running_sample_length);
which is preceded by a comment that talks about how this is accessed from critical code and explicitly mentions NMI's.
So protection them against interrupts isn't actually going to *fix* anything.
Doing a
git grep DEFINE_PER_CPU.*64
isn't likely to find everything, but maybe it's a representative sample. There aren't that many of those things, and some of them are very much ok (ie only 64-bit architectures, or explicitly using "atomic64_t" to avoid access issues)
I dunno. I have pulled you change, but it does make me go "people are doing something wrong".
Maybe we could just aim to disallow everything but CPU-native accesses?
Linus
| |