public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Avi Kivity <avi@scylladb.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-api <linux-api@vger.kernel.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Boqun Feng <boqun.feng@gmail.com>, Andrew Hunter <ahh@google.com>,
	maged michael <maged.michael@gmail.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Dave Watson <davejwatson@fb.com>, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrea Parri <parri.andrea@gmail.com>,
	"Russell King, ARM Linux" <linux@armlinux.org.uk>,
	Greg Hackmann <ghackmann@google.com>,
	Will Deacon <will.deacon@arm.com>, David Sehr <sehr@google.com>,
	x86 <x86@kernel.org>
Subject: Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration
Date: Tue, 14 Nov 2017 17:31:59 +0100	[thread overview]
Message-ID: <20171114163159.GD3165@worktop.lehotels.local> (raw)
In-Reply-To: <CALCETrXpR7ai047pHtdQe5J+FpuFO5ekeeEqLUt1wVLopyNt_Q@mail.gmail.com>

On Tue, Nov 14, 2017 at 08:16:09AM -0800, Andy Lutomirski wrote:
> What guarantees that there's an IPI?  Do we never do a syscall, get
> migrated during syscall processing (due to cond_resched(), for
> example), and land on another CPU that just happened to already be
> scheduling?

Possible, the other CPU could've pulled the task because it went idle.
No IPIs involved in that scenario.

And if it was running a different thread of the same process prior to
that, we'll also not do switch_mm().

So yes, it is possible to construct a migration scenario without core
serializing instructions (of the CPUID/MOV-CR kind, not the LOCK prefix
kind).

Note that that still requires a multi-threaded process.

There is another scenario; where the NOHZ load-balancer moves the task;
such that the NOHZ load balancing CPU is a 3rd CPU. In that case there
is an interrupt (to affect the load-balancing) but it will not land on
the CPU that's going to run the task.

This could happen for a single threaded task; since I suppose the NOHZ
idle CPU that's going to be the victim could have ran our task last and
still lazily have the mm.

Very tricky to make work, not to mention that I suspect actually going
idle will kill a whole bunch of state real quick.

  reply	other threads:[~2017-11-14 16:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-10 21:12 [RFC PATCH 0/2] x86: Fix missing core serialization on migration Mathieu Desnoyers
2017-11-10 21:12 ` [RFC PATCH 1/2] x86: Introduce sync_core_before_usermode Mathieu Desnoyers
2017-11-10 21:12 ` [RFC PATCH 2/2] Fix: x86: Add missing core serializing instruction on migration Mathieu Desnoyers
2017-11-10 21:36 ` [RFC PATCH 0/2] x86: Fix missing core serialization " Linus Torvalds
2017-11-10 21:57   ` Mathieu Desnoyers
2017-11-10 22:12     ` Linus Torvalds
2017-11-13 16:56     ` Mathieu Desnoyers
2017-11-13 17:14       ` Linus Torvalds
2017-11-14 14:53       ` Avi Kivity
2017-11-14 15:17         ` Mathieu Desnoyers
2017-11-14 15:42           ` Avi Kivity
2017-11-14 16:05           ` Peter Zijlstra
2017-11-14 16:08             ` Peter Zijlstra
2017-11-14 16:49               ` Mathieu Desnoyers
2017-11-14 17:03                 ` Avi Kivity
2017-11-14 17:10                   ` Mathieu Desnoyers
2017-11-14 17:31                     ` Linus Torvalds
2017-11-14 16:10             ` Andy Lutomirski
2017-11-14 16:13               ` Thomas Gleixner
2017-11-14 16:16                 ` Andy Lutomirski
2017-11-14 16:31                   ` Peter Zijlstra [this message]
2017-11-14 17:17                     ` Daniel Bristot de Oliveira
2017-11-14 17:40                       ` Peter Zijlstra
2017-11-14 18:01                         ` Daniel Bristot de Oliveira
2017-11-14 18:17                           ` Peter Zijlstra
2017-11-14 18:24                             ` Daniel Bristot de Oliveira

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=20171114163159.GD3165@worktop.lehotels.local \
    --to=peterz@infradead.org \
    --cc=ahh@google.com \
    --cc=avi@scylladb.com \
    --cc=benh@kernel.crashing.org \
    --cc=boqun.feng@gmail.com \
    --cc=davejwatson@fb.com \
    --cc=ghackmann@google.com \
    --cc=hpa@zytor.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=luto@kernel.org \
    --cc=maged.michael@gmail.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=parri.andrea@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=sehr@google.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox