diff options
author | Andy Lutomirski <[email protected]> | 2017-09-07 22:06:58 -0700 |
---|---|---|
committer | Ingo Molnar <[email protected]> | 2017-09-13 09:52:37 +0200 |
commit | f34902c5c6c08024371202a680ce69f2d488776d (patch) | |
tree | e4c2a3846bc496c2e11ead25042afd0cd613be19 /fs/btrfs/async-thread.c | |
parent | a376e7f99be7c1e15b2d986e49b2bec834904381 (diff) |
x86/hibernate/64: Mask off CR3's PCID bits in the saved CR3
Jiri reported a resume-from-hibernation failure triggered by PCID.
The root cause appears to be rather odd. The hibernation asm
restores a CR3 value that comes from the image header. If the image
kernel has PCID on, it's entirely reasonable for this CR3 value to
have one of the low 12 bits set. The restore code restores it with
CR4.PCIDE=0, which means that those low 12 bits are accepted by the
CPU but are either ignored or interpreted as a caching mode. This
is odd, but still works. We blow up later when the image kernel
restores CR4, though, since changing CR4.PCIDE with CR3[11:0] != 0
is illegal. Boom!
FWIW, it's entirely unclear to me what's supposed to happen if a PAE
kernel restores a non-PAE image or vice versa. Ditto for LA57.
Reported-by: Jiri Kosina <[email protected]>
Tested-by: Jiri Kosina <[email protected]>
Signed-off-by: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Fixes: 660da7c9228f ("x86/mm: Enable CR4.PCIDE on supported systems")
Link: http://lkml.kernel.org/r/18ca57090651a6341e97083883f9e814c4f14684.1504847163.git.luto@kernel.org
Signed-off-by: Ingo Molnar <[email protected]>
Diffstat (limited to 'fs/btrfs/async-thread.c')
0 files changed, 0 insertions, 0 deletions