linux-kernel - Re: [GIT PULL] percpu fixes for v4.14-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFxgVydrTH0z_goh=HMWTrY7xS8Eh0QDuL2jR7ojLpu3pw@mail.gmail.com>
Date:   Tue, 3 Oct 2017 10:27:42 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Tejun Heo <tj@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Christoph Lameter <cl@...ux.com>,
        Dennis Zhou <dennisszhou@...il.com>
Subject: Re: [GIT PULL] percpu fixes for v4.14-rc3

On Tue, Oct 3, 2017 at 6:26 AM, Tejun Heo <tj@...nel.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