All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Will Deacon <will@kernel.org>, Andy Lutomirski <luto@kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	X86 ML <x86@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Mackerras <paulus@samba.org>,
	stable <stable@vger.kernel.org>
Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()
Date: Tue, 5 Jan 2021 17:37:31 +0100	[thread overview]
Message-ID: <20210105163731.GM3040@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <7BFAB97C-1949-46A3-A1E2-DFE108DC7D5E@amacapital.net>

On Tue, Jan 05, 2021 at 08:20:51AM -0800, Andy Lutomirski wrote:
> >     Interestingly, the architecture recently added a control bit to remove
> >     this synchronisation from exception return, so if we set that then we'd
> >     have a problem with SYNC_CORE and adding an ISB would be necessary (and
> >     we could probable then make kernel->kernel returns cheaper, but I
> >     suspect we're relying on this implicit synchronisation in other places
> >     too).
> > 
> 
> Is ISB just a context synchronization event or does it do more?

IIRC it just the instruction sync (like power ISYNC).

> On x86, it’s very hard to tell that MFENCE does any more than LOCK,
> but it’s much slower.  And we have LFENCE, which, as documented,
> doesn’t appear to have any semantics at all.  (Or at least it didn’t
> before Spectre.)

AFAIU MFENCE is a completion barrier, while LOCK prefix is not. A bit
like ARM's DSB vs DMB.

It is for this reason that mb() is still MFENCE, while our smp_mb() is a
LOCK prefixed NO-OP.

And yes, LFENCE used to be poorly defined and it was sometimes
understood to be a completion barrier relative to prior LOADs, while it
is now a completion barrier for any prior instruction, and really should
be renamed to IFENCE.



WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Arnd Bergmann <arnd@arndb.de>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andy Lutomirski <luto@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Paul Mackerras <paulus@samba.org>,
	stable <stable@vger.kernel.org>, Will Deacon <will@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()
Date: Tue, 5 Jan 2021 17:37:31 +0100	[thread overview]
Message-ID: <20210105163731.GM3040@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <7BFAB97C-1949-46A3-A1E2-DFE108DC7D5E@amacapital.net>

On Tue, Jan 05, 2021 at 08:20:51AM -0800, Andy Lutomirski wrote:
> >     Interestingly, the architecture recently added a control bit to remove
> >     this synchronisation from exception return, so if we set that then we'd
> >     have a problem with SYNC_CORE and adding an ISB would be necessary (and
> >     we could probable then make kernel->kernel returns cheaper, but I
> >     suspect we're relying on this implicit synchronisation in other places
> >     too).
> > 
> 
> Is ISB just a context synchronization event or does it do more?

IIRC it just the instruction sync (like power ISYNC).

> On x86, it’s very hard to tell that MFENCE does any more than LOCK,
> but it’s much slower.  And we have LFENCE, which, as documented,
> doesn’t appear to have any semantics at all.  (Or at least it didn’t
> before Spectre.)

AFAIU MFENCE is a completion barrier, while LOCK prefix is not. A bit
like ARM's DSB vs DMB.

It is for this reason that mb() is still MFENCE, while our smp_mb() is a
LOCK prefixed NO-OP.

And yes, LFENCE used to be poorly defined and it was sometimes
understood to be a completion barrier relative to prior LOADs, while it
is now a completion barrier for any prior instruction, and really should
be renamed to IFENCE.



WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Andy Lutomirski <luto@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Paul Mackerras <paulus@samba.org>,
	stable <stable@vger.kernel.org>, Will Deacon <will@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()
Date: Tue, 5 Jan 2021 17:37:31 +0100	[thread overview]
Message-ID: <20210105163731.GM3040@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <7BFAB97C-1949-46A3-A1E2-DFE108DC7D5E@amacapital.net>

On Tue, Jan 05, 2021 at 08:20:51AM -0800, Andy Lutomirski wrote:
> >     Interestingly, the architecture recently added a control bit to remove
> >     this synchronisation from exception return, so if we set that then we'd
> >     have a problem with SYNC_CORE and adding an ISB would be necessary (and
> >     we could probable then make kernel->kernel returns cheaper, but I
> >     suspect we're relying on this implicit synchronisation in other places
> >     too).
> > 
> 
> Is ISB just a context synchronization event or does it do more?

IIRC it just the instruction sync (like power ISYNC).

> On x86, it’s very hard to tell that MFENCE does any more than LOCK,
> but it’s much slower.  And we have LFENCE, which, as documented,
> doesn’t appear to have any semantics at all.  (Or at least it didn’t
> before Spectre.)

AFAIU MFENCE is a completion barrier, while LOCK prefix is not. A bit
like ARM's DSB vs DMB.

It is for this reason that mb() is still MFENCE, while our smp_mb() is a
LOCK prefixed NO-OP.

And yes, LFENCE used to be poorly defined and it was sometimes
understood to be a completion barrier relative to prior LOADs, while it
is now a completion barrier for any prior instruction, and really should
be renamed to IFENCE.



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-05 16:39 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-27 18:28 [RFC please help] membarrier: Rewrite sync_core_before_usermode() Andy Lutomirski
2020-12-27 18:28 ` Andy Lutomirski
2020-12-27 18:28 ` Andy Lutomirski
2020-12-27 20:18 ` Mathieu Desnoyers
2020-12-27 20:18   ` Mathieu Desnoyers
2020-12-27 21:36   ` Andy Lutomirski
2020-12-27 21:36     ` Andy Lutomirski
2020-12-27 21:36     ` Andy Lutomirski
2020-12-28 10:25     ` Russell King - ARM Linux admin
2020-12-28 10:25       ` Russell King - ARM Linux admin
2020-12-28 10:25       ` Russell King - ARM Linux admin
2020-12-28 17:14       ` Andy Lutomirski
2020-12-28 17:14         ` Andy Lutomirski
2020-12-28 17:14         ` Andy Lutomirski
2020-12-28 17:23         ` Russell King - ARM Linux admin
2020-12-28 17:23           ` Russell King - ARM Linux admin
2020-12-28 17:23           ` Russell King - ARM Linux admin
2020-12-28 18:10           ` Andy Lutomirski
2020-12-28 18:10             ` Andy Lutomirski
2020-12-28 18:10             ` Andy Lutomirski
2020-12-28 18:29         ` Jann Horn
2020-12-28 18:29           ` Jann Horn
2020-12-28 18:29           ` Jann Horn
2020-12-28 18:50           ` Andy Lutomirski
2020-12-28 18:50             ` Andy Lutomirski
2020-12-28 18:50             ` Andy Lutomirski
2020-12-28 19:08           ` Russell King - ARM Linux admin
2020-12-28 19:08             ` Russell King - ARM Linux admin
2020-12-28 19:08             ` Russell King - ARM Linux admin
2020-12-28 19:44             ` Andy Lutomirski
2020-12-28 19:44               ` Andy Lutomirski
2020-12-28 19:44               ` Andy Lutomirski
2020-12-28 20:24               ` Russell King - ARM Linux admin
2020-12-28 20:24                 ` Russell King - ARM Linux admin
2020-12-28 20:24                 ` Russell King - ARM Linux admin
2020-12-28 20:40                 ` Mathieu Desnoyers
2020-12-28 20:40                   ` Mathieu Desnoyers
2020-12-28 20:32               ` Mathieu Desnoyers
2020-12-28 20:32                 ` Mathieu Desnoyers
2020-12-28 21:06                 ` Andy Lutomirski
2020-12-28 21:06                   ` Andy Lutomirski
2020-12-28 21:06                   ` Andy Lutomirski
2020-12-28 21:26                   ` Mathieu Desnoyers
2020-12-28 21:26                     ` Mathieu Desnoyers
2020-12-29  0:36                   ` Nicholas Piggin
2020-12-29  0:36                     ` Nicholas Piggin
2020-12-29  0:36                     ` Nicholas Piggin
2020-12-29  0:56                     ` Andy Lutomirski
2020-12-29  0:56                       ` Andy Lutomirski
2020-12-29  0:56                       ` Andy Lutomirski
2020-12-29  3:09                       ` Nicholas Piggin
2020-12-29  3:09                         ` Nicholas Piggin
2020-12-29  3:09                         ` Nicholas Piggin
2020-12-29 10:44                         ` Russell King - ARM Linux admin
2020-12-29 10:44                           ` Russell King - ARM Linux admin
2020-12-29 10:44                           ` Russell King - ARM Linux admin
2020-12-30  2:33                           ` Nicholas Piggin
2020-12-30  2:33                             ` Nicholas Piggin
2020-12-30  2:33                             ` Nicholas Piggin
2020-12-30 10:00                             ` Russell King - ARM Linux admin
2020-12-30 10:00                               ` Russell King - ARM Linux admin
2020-12-30 10:00                               ` Russell King - ARM Linux admin
2020-12-30 10:58                               ` Russell King - ARM Linux admin
2020-12-30 10:58                                 ` Russell King - ARM Linux admin
2020-12-30 10:58                                 ` Russell King - ARM Linux admin
2020-12-30 11:57                                 ` Nicholas Piggin
2020-12-30 11:57                                   ` Nicholas Piggin
2020-12-30 11:57                                   ` Nicholas Piggin
2020-12-28 21:09     ` Mathieu Desnoyers
2020-12-28 21:09       ` Mathieu Desnoyers
2020-12-29  0:30       ` Andy Lutomirski
2020-12-29  0:30         ` Andy Lutomirski
2020-12-29  0:30         ` Andy Lutomirski
2020-12-29  0:11 ` Nicholas Piggin
2020-12-29  0:11   ` Nicholas Piggin
2020-12-29  0:11   ` Nicholas Piggin
2020-12-29  0:36   ` Andy Lutomirski
2020-12-29  0:36     ` Andy Lutomirski
2020-12-29  0:36     ` Andy Lutomirski
2020-12-29  3:31     ` Nicholas Piggin
2020-12-29  3:31       ` Nicholas Piggin
2020-12-29  3:31       ` Nicholas Piggin
2021-01-01 18:33     ` David Laight
2021-01-01 18:33       ` David Laight
2021-01-01 18:33       ` David Laight
2021-01-05 13:26     ` Will Deacon
2021-01-05 13:26       ` Will Deacon
2021-01-05 13:26       ` Will Deacon
2021-01-05 16:20       ` Andy Lutomirski
2021-01-05 16:20         ` Andy Lutomirski
2021-01-05 16:20         ` Andy Lutomirski
2021-01-05 16:37         ` Peter Zijlstra [this message]
2021-01-05 16:37           ` Peter Zijlstra
2021-01-05 16:37           ` Peter Zijlstra
2021-01-05 22:41         ` Will Deacon
2021-01-05 22:41           ` Will Deacon
2021-01-05 22:41           ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210105163731.GM3040@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    --cc=stable@vger.kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.