linux-kernel - Re: [RFC PATCH 2/2] membarrier: provide register sync core cmd

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] [day] [month] [year] [list]

Date:   Wed, 30 Aug 2017 11:01:31 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Andrew Hunter <ahh@...gle.com>,
        maged michael <maged.michael@...il.com>,
        gromer <gromer@...gle.com>, Avi Kivity <avi@...lladb.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Dave Watson <davejwatson@...com>,
        Andy Lutomirski <luto@...nel.org>,
        Will Deacon <will.deacon@....com>,
        Hans Boehm <hboehm@...gle.com>
Subject: Re: [RFC PATCH 2/2] membarrier: provide register sync core cmd

On Wed, Aug 30, 2017 at 05:53:53PM +0000, Mathieu Desnoyers wrote:
> ----- On Aug 28, 2017, at 1:49 PM, Paul E. McKenney paulmck@...ux.vnet.ibm.com wrote:
> 
> > On Sun, Aug 27, 2017 at 09:39:54PM +0000, Mathieu Desnoyers wrote:
> >> ----- On Aug 27, 2017, at 2:00 PM, Paul E. McKenney paulmck@...ux.vnet.ibm.com
> >> wrote:
> >> 
> >> > On Sun, Aug 27, 2017 at 08:52:58PM +0000, Mathieu Desnoyers wrote:
> >> >> ----- On Aug 27, 2017, at 1:35 PM, Paul E. McKenney paulmck@...ux.vnet.ibm.com
> >> >> wrote:
> >> >> 
> >> >> > On Sun, Aug 27, 2017 at 12:54:04PM -0700, Mathieu Desnoyers wrote:
> >> >> >> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier
> >> >> >> system call. It allows processes to register their intent to have their
> >> >> >> threads issue core serializing barriers in addition to memory barriers
> >> >> >> whenever a membarrier command is performed.
> >> >> >> 
> >> >> >> It is relevant for reclaim of JIT code, which requires to issue core
> >> >> >> serializing barriers on all threads running on behalf of a process
> >> >> >> after ensuring the old code is not visible anymore, before re-using
> >> >> >> memory for new code.
> >> >> >> 
> >> >> >> When a processes returns from a MEMBARRIER_CMD_REGISTER_SYNC_CORE
> >> >> >> command, it is guaranteed that all following MEMBARRIER_CMD_SHARED and
> >> >> >> MEMBARRIER_CMD_PRIVATE_EXPEDITED issue core serializing barriers, in
> >> >> >> addition to the memory barriers, on all of its running threads.
> >> >> > 
> >> >> > I have queued both of these for testing and review:
> >> >> > 
> >> >> >  git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> >> >> >  f54cf5123eb9 ("membarrier: Speed up single-threaded private cmd")
> >> >> >  0d6eb99818da ("membarrier: Provide register sync core cmd")
> >> >> > 
> >> >> > Could the people who asked for this please test it?  The second commit
> >> >> > is non-obvious enough to need some careful review and intensive testing
> >> >> > before I can in good conscious pass it upstream.
> >> >> 
> >> >> Thanks Paul!
> >> >> 
> >> >> Can you pick up my v2 instead ? I added benchmarks in the changelog and
> >> >> documented the new command in the membarrier public header. No changes
> >> >> otherwise.
> >> > 
> >> > It looks like 0day Test Robot also wants some additional header files.
> >> > Could you please send me a v3 with its complaints addressed?
> >> 
> >> I sent a separate patch implementing sync_core() on xtensa. It should
> >> be applied before this patch.
> > 
> > And it looks like we also need a sync_core() on every CPU family other
> > than x86, which already has one.  Do we want to make this capability
> > depend on an ARCH_ kconfig option, or should we just bit the bullet and
> > implement sync_core() everywhere?
> > 
> > (I had to drop this commit due to downstream complaints.  Left to myself,
> > I would take the ARCH_ approach, then add it back in, but please let me
> > know how you would like to proceed.)
> 
> I plan to go with the ARCH_ approach indeed.

Sounds good, looking forward to seeing it.  ;-)

							Thanx, Paul