lkml.org 
[lkml]   [2017]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2017-10-03 19:28    [W:0.050 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site