linux-kernel - Re: [RFC PATCH 4/4] Fix: sched/membarrier: p->mm->membarrier

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-=wgC8YspwtUeaV9ZwHjZDfXaJaT7i4v==Dp-vnVOF5i6qg@mail.gmail.com>
Date:   Thu, 12 Sep 2019 15:24:35 +0100
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Will Deacon <will@...nel.org>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Peter Zijlstra <peterz@...radead.org>,
        paulmck <paulmck@...ux.ibm.com>, Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Oleg Nesterov <oleg@...hat.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Russell King, ARM Linux" <linux@...linux.org.uk>,
        Chris Metcalf <cmetcalf@...hip.com>,
        Chris Lameter <cl@...ux.com>, Kirill Tkhai <tkhai@...dex.ru>,
        Mike Galbraith <efault@....de>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH 4/4] Fix: sched/membarrier: p->mm->membarrier_state
 racy load (v2)

On Thu, Sep 12, 2019 at 2:48 PM Will Deacon <will@...nel.org> wrote:
>
> So the man page for sys_membarrier states that the expedited variants "never
> block", which feels pretty strong. Do any other system calls claim to
> provide this guarantee without a failure path if blocking is necessary?

The traditional semantics for "we don't block" is that "we block on
memory allocations and locking and user accesses etc, but  we don't
wait for our own IO".

So there may be new IO started (and waited on) as part of allocating
new memory etc, or in just paging in user memory, but the IO that the
operation _itself_ explicitly starts is not waited on.

No system call should ever be considered "atomic" in any sense. If
you're doing RT, you should maybe expect "getpid()" to not ever block,
but that's just about the exclusive list of truly nonblocking system
calls, and even that can be preempted.

            Linus