Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 12 Dec 2017 14:10:00 -0800 | Subject | Re: Linux 4.15-rc2: Regression in resume from ACPI S3 |
| |
On Tue, Dec 12, 2017 at 10:36 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Dec 12, 2017 at 10:05 AM, Andy Lutomirski <luto@kernel.org> 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?
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes&id=cb855aa9679a15adbe43732f5854270de2b35856
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.)
| |