linux-kernel - Re: [PATCH 0/3] task: Making tasks on the runqueue rcu protected

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: <CAHk-=wgQ_tZXQkovVked+nEsZhZqGVNnKmoy3b699dycZqCdKA@mail.gmail.com>
Date:   Tue, 3 Sep 2019 08:44:40 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Paul E. McKenney" <paulmck@...ux.ibm.com>
Cc:     Oleg Nesterov <oleg@...hat.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Peter Zijlstra <peterz@...radead.org>,
        Chris Metcalf <cmetcalf@...hip.com>,
        Christoph Lameter <cl@...ux.com>,
        Kirill Tkhai <tkhai@...dex.ru>, Mike Galbraith <efault@....de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Davidlohr Bueso <dave@...olabs.net>
Subject: Re: [PATCH 0/3] task: Making tasks on the runqueue rcu protected

On Mon, Sep 2, 2019 at 9:50 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> I have split this work into 3 simple patches, so the code is straight
> forward to review and so that if any mistakes slip in it is easy to
> bisect them.  In the process of review what it takes to remove
> task_rcu_dereference I found yet another user of tasks on the
> runqueue in rcu context; the rcuwait_event code.  That code only needs
> it now unnecessary limits removed.

Looks very good to me.

I think PeterZ is right that the rcu_assign_pointer() in [PATCH 2/3]
could be a RCU_INIT_POINTER() due to condition #3 in the
RCU_INIT_POINTER rules. The initialization of the pointer value simply
has nothing to do with what the pointer points to - we're just
switching it to another case.

That said, it won't affect any of the core architectures much, because
smp_store_release() isn't that expensive (it's just a compiler barrier
on x86, it's a cheap instruction on arm64, and it should be very cheap
on any other architecture too unless they do insane things - even on
powerpc, which is about the worst case for any barriers, it's just an
lwsync).

It might be good to have Paul _look_ at it, and because of the minimal
performance impact I don't worry about it too much if it happens
later, but it should be something we keep in mind.

                  Linus