lkml.org 
[lkml]   [2017]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Linux 4.15-rc2: Regression in resume from ACPI S3
    On Sun, Dec 10, 2017 at 1:28 PM, Linus Torvalds
    <torvalds@linux-foundation.org> wrote:
    >
    > That said, this *all* smells wrong. Why is there a special
    > fix_processor_context() function at all with different 32-bit and
    > 64-bit behavior? This code is all written to be maximally confusing.

    Hmm. Looking a bit more at this, I think it should be solved by:

    - load the original read-write GDT early, along with the IDT.

    We have already saved it off in __save_processor_state(), and it may
    have already gotten loaded very early in at least some of the paths,
    but it definitely hasn't gotten reloaded in all the paths (think
    "suspend/resume testing" etc).

    - add the LDT descriptor to the save area too, exactly like we
    already have IDT/GDT.

    Then, we can do "load_ldt()" early (along with IDT and GDT).

    - now we can just load all the segments early, and get the percpu and
    stack canary stuff without any special cases

    - 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.

    - now that we have a fully working system, then the
    "fix_processor_context()" code can do the "fancy" stuff like setting
    up the RO fixmap GDT and re-initializing the TLB state. Those want
    percpu stuff.

    In other words, why not try to organize this so that we do a simple
    and fairly mindless restore of the low-level state first? Avoid all
    the "system is halfway up" crud.

    Would that work for people? Andy?

    Linus

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