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  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]
Date:   Mon, 16 Jan 2017 15:50:40 -0800
From:   Linus Torvalds <>
To:     Mathieu Desnoyers <>
Cc:     "Paul E. McKenney" <>,
        linux-kernel <>,
        Josh Triplett <>,
        KOSAKI Motohiro <>,
        rostedt <>,
        Nicholas Miell <>,
        Ingo Molnar <>,
        One Thousand Gnomes <>,
        Lai Jiangshan <>,
        Stephen Hemminger <>,
        Thomas Gleixner <>,
        Peter Zijlstra <>,
        David Howells <>,
        bobby prani <>,
        Michael Kerrisk <>,
        Shuah Khan <>,
        Andrew Morton <>
Subject: Re: [RFC PATCH] membarrier: handle nohz_full with expedited thread registration

On Mon, Jan 16, 2017 at 2:56 PM, Mathieu Desnoyers
<> wrote:
> So for both register and unregister functions, as well as the use in
> membarrier_nohz_full_expedited(), disabling interrupts around the rq
> lock should fix this. But perhaps it would be wiser trying not to use the
> rq lock at all.


>> (d) when it doesn't even make any sense in the first place for a
>> per-thread value that is never modified by any other threads!
> The variable "membarrier_expedited" is indeed only modified by the
> current thread, but it is read by other threads calling
> membarrier_nohz_full_expedited().

Why not just make the write be a "smp_store_release()", and the read
be a "smp_load_acquire()". That guarantees a certain amount of
ordering. The only amount that I suspect makes sense, in fact.

But it's not clear what the problem is, so..

>> Oh, and the clone semantics make no sense either.
> Currently, this patch clears the state on exec and when forking a new thread,
> but keeps the thread state when forking a new process, which AFAIU is
> in line with current practices. But perhaps not, what I am missing ?

I'm not seeing how a regular fork() could possibly ever make sense to
have the membarrier state in the newly forked process. Not that
"fork()" is really well-defined for within a single thread anyway (it
actually is as far as Linux is concerned, but not in POSIX, afaik).

So if there is no major reason for it, I would strongly suggest that
_if_ all this makes sense in the first place, the membarrier thing
should just be cleared unconditionally both for exec and for


Powered by blists - more mailing lists