Re: [RFC PATCH 0/2] x86: Fix missing core serialization on migration

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

----- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:

> ----- On Nov 10, 2017, at 4:36 PM, Linus Torvalds torvalds@linux-foundation.org
> wrote:
> 
>> On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
>> <mathieu.desnoyers@efficios.com> wrote:
>>> x86 can return to user-space through sysexit and sysretq, which are not
>>> core serializing. This breaks expectations from user-space about
>>> sequential consistency from a single-threaded self-modifying program
>>> point of view in specific migration patterns.
>>>
>>> Feedback is welcome,
>> 
>> We should check with Intel. I would actually be surprised if the I$
>> can be out of sync with the D$ after a sysretq.  It would actually
>> break things like "read code from disk" too in theory.
> 
> That core serializing instruction is not that much about I$ vs D$
> consistency, but rather about the processor speculatively executing code
> ahead of its retirement point. Ref. Intel Architecture Software Developer's
> Manual, Volume 3: System Programming.
> 
> 7.1.3. "Handling Self- and Cross-Modifying Code":
> 
> "The act of a processor writing data into a currently executing code segment
> with the intent of
> executing that data as code is called self-modifying code. Intel Architecture
> processors exhibit
> model-specific behavior when executing self-modified code, depending upon how
> far ahead of
> the current execution pointer the code has been modified. As processor
> architectures become
> more complex and start to speculatively execute code ahead of the retirement
> point (as in the P6
> family processors), the rules regarding which code should execute, pre- or
> post-modification,
> become blurred. [...]"
> 
> AFAIU, this core serializing instruction seems to be needed for use-cases of
> self-modifying code, but not for the initial load of a program from disk,
> as the processor has no way to have speculatively executed any of its
> instructions.

I figured out what you're pointing to: if exec() is executed by a previously
running thread, and there is no core serializing instruction between program
load and return to user-space, the kernel ends up acting like a JIT, indeed.

Therefore, we'd also need to invoke sync_core_before_usermode() after loading
the program.

Let's wait to hear back from hpa,

Thanks,

Mathieu


> 
> Hopefully hpa can tell us more about this,
> 
> Thanks,
> 
> Mathieu
> 
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com