[lkml]   [2017]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux 4.15-rc2: Regression in resume from ACPI S3
On Tue, Dec 12, 2017 at 10:36 AM, Linus Torvalds
<> wrote:
> On Tue, Dec 12, 2017 at 10:05 AM, Andy Lutomirski <> wrote:
>>> - do NOT use "load_gs_index()", which does that swapgs dance (twice!)
>>> and plays with interrupt state. Just load the segment register, and
>>> then do the wrmsrl() of the {FS,GS,KERNEL_GS}_BASE values. There is no
>>> need for the swapgs dance.
>> Using what helper? On x86_64, it can fault, and IIRC we explicitly
>> don't allow loadsegment(gs, ...).
> Just do the loadsegment() thing. The fact that we don't have a gs
> version of it is legacy - to catch bad users. It shouldn't stop us
> from having good users.
> That said - can it really fault? Because if it can, then why can't %fs
> fault? And on x86-64, we just do
> asm volatile ("movw %0, %%fs" :: "r" (ctxt->fs));
> and don't actually use 'loadsegment()' for _any_ of the segments. We
> only do the fault protection on 32-bit.
> In fact, we really should try to avoid taking faults here anyway,
> shouldn't we? We haven't loaded enough of the context yet.
> Hmm.
> Maybe we should load only the fixed kernel segments at this point, and
> then do all the loadsegment() of gs/fs in the later phase when we're
> all set up.
> THERE we can do the swapgs dance with interrupt tracing etc, because
> *there* we actually are fully set up. I guess that means reloading the
> FS/GS base MSR's,

Like this?

I've barely tested it. It suspended and resumed once in a 64-bit VM.
It compiles on 32-bit.

(That link might not work for a little bit. I'm not sure what's up.)

 \ /
  Last update: 2017-12-12 23:10    [W:0.252 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site