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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Sep 2017 18:01:30 +0100 From: Will Deacon <will.deacon@....com> To: Hans Boehm <hboehm@...gle.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, 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>, Russell King <linux@...linux.org.uk>, Greg Hackmann <ghackmann@...gle.com> Subject: Re: [RFC PATCH v3] membarrier: provide core serialization On Thu, Sep 07, 2017 at 05:03:49PM -0700, Hans Boehm wrote: > > [Mathieu: ] > > > > Assuming we don't need a sync core before updating the old code, an > > aggressive approach would be: > > > > reclaim and re-use (aggressive): > > > > 1- userspace unpublish all reference to old code, > > 2- userspace ensure no thread use the old code anymore (e.g. URCU), > > 3- userspace updates old code -> new code > > 4- issue data cache flush for the modified range (if needed) > > 5- sys_membarrier > > - for each executing threads > > - issue core serializing barrier > > 6- issue instruction cache flush for the modified range (if needed) > > (may be required on all active threads on some architectures) > > 7- userspace publish reference to new code > > > My assumption was that right sequence here, at least on Aarch64, is to > do 5 and 6 in the opposite order; flush the icache,which I believe can > be done from the thread that wrote the code, and then issue a sys_membarrier > for the core serializing barrier. > > It would be useful to get that clarified. FWIW, Mathieu and I spent a while talking about this during LPC last week and ended up agreeing that the ISB (core serialisation) is required *after* the cache-maintenance to publish the new code has completed. Will
Powered by blists - more mailing lists