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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 7 Oct 2017 17:10:04 +0200
From:   Andrea Parri <>
To:     Peter Zijlstra <>
Cc:     Mathieu Desnoyers <>,
        "Paul E. McKenney" <>,
        linux-kernel <>,
        Ingo Molnar <>,
        Lai Jiangshan <>,
        dipankar <>,
        Andrew Morton <>,
        Josh Triplett <>,
        Thomas Gleixner <>,
        rostedt <>,
        David Howells <>,
        Eric Dumazet <>,
        fweisbec <>, Oleg Nesterov <>,
        Boqun Feng <>,
        Andrew Hunter <>,
        maged michael <>,
        gromer <>, Avi Kivity <>,
        Benjamin Herrenschmidt <>,
        Paul Mackerras <>,
        Michael Ellerman <>,
        Dave Watson <>,
        Alan Stern <>,
        Will Deacon <>,
        Andy Lutomirski <>,
        Ingo Molnar <>,
        Alexander Viro <>,
        Nicholas Piggin <>,
        linuxppc-dev <>,
        linux-arch <>
Subject: Re: [PATCH tip/core/rcu 1/3] membarrier: Provide register expedited
 private command

On Fri, Oct 06, 2017 at 10:32:19AM +0200, Peter Zijlstra wrote:
> > AFAIU the scheduler rq->lock is held while preemption is disabled.
> > synchronize_sched() is used here to ensure that all pre-existing
> > preempt-off critical sections have completed.
> > 
> > So saying that we use synchronize_sched() to synchronize with rq->lock
> > would be stretching the truth a bit. It's actually only true because the
> > scheduler holding the rq->lock is surrounded by a preempt-off
> > critical section.
> No, rq->lock is sufficient, note that rq->lock is a raw_spinlock_t which
> implies !preempt. Yes, we also surround the rq->lock usage with a
> slightly larger preempt_disable() section but that's not in fact
> required for this.

That's what it is, according to the current sources: we seemed to agree that
a preempt-off critical section is what we rely on here and that the start of
this critical section is not marked by that raw_spin_lock.


Powered by blists - more mailing lists