Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 1 Dec 2020 09:55:17 -0800 | Subject | Re: [PATCH 2/3] membarrier: Add an actual barrier before rseq_preempt() |
| |
On Tue, Dec 1, 2020 at 6:31 AM Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > ----- On Dec 1, 2020, at 5:06 AM, Peter Zijlstra peterz@infradead.org wrote: > > > On Mon, Nov 30, 2020 at 09:50:34AM -0800, Andy Lutomirski wrote: > >> It seems to be that most RSEQ membarrier users will expect any > >> stores done before the membarrier() syscall to be visible to the > >> target task(s). While this is extremely likely to be true in > >> practice, nothing actually guarantees it by a strict reading of the > >> x86 manuals. Rather than providing this guarantee by accident and > >> potentially causing a problem down the road, just add an explicit > >> barrier. > > > > A very long time ago; when Jens introduced smp_call_function(), we had > > this discussion. At the time Linus said that receiving an interrupt had > > better be ordering, and if it is not, then it's up to the architecture > > to handle that before it gets into the common code. > > > > https://lkml.kernel.org/r/alpine.LFD.2.00.0902180744520.21686@localhost.localdomain > > > > Maybe we want to revisit this now, but there might be a fair amount of > > code relying on all this by now. > > > > Documenting it better might help. > > Considering that we already have this in membarrier ipi_mb : > > static void ipi_mb(void *info) > { > smp_mb(); /* IPIs should be serializing but paranoid. */ > } > > I think it makes sense to add this same smp_mb() in the ipi_rseq if the expected > behavior is to order memory accesses as well, and have the same level of paranoia as > the ipi_mb.
That was my reasoning.
| |