Messages in this thread Patch in this message | | | From | Tony Luck <> | Subject | [PATCH] x86/mm: Don't try to change poison pages to uncacheable in a guest | Date | Tue, 5 May 2020 11:46:48 -0700 |
| |
An interesting thing happened when a guest Linux instance took a machine check. The VMM unmapped the bad page from guest physical space and passed the machine check to the guest.
Linux took all the normal actions to offline the page from the process that was using it. But then guest Linux crashed because it said there was a second machine check inside the kernel with this stack trace:
do_memory_failure set_mce_nospec set_memory_uc _set_memory_uc change_page_attr_set_clr cpa_flush clflush_cache_range_opt
This was odd, because a CLFLUSH instruction shouldn't raise a machine check (it isn't consuming the data). Further investigation showed that the VMM had passed in another machine check because is appeared that the guest was accessing the bad page.
Fix is to check whether Linux is running as a guest. If it is, there is no point in trying to change the cache mode of the bad page. The VMM has taken the whole page away.
Reported-by: Jue Wang <juew@google.com> Tested-by: Jue Wang <juew@google.com> Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()") Cc: <stable@vger.kernel.org> Signed-off-by: Tony Luck <tony.luck@intel.com> --- arch/x86/include/asm/set_memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/arch/x86/include/asm/set_memory.h b/arch/x86/include/asm/set_memory.h index ec2c0a094b5d..e8b7e8a82d7a 100644 --- a/arch/x86/include/asm/set_memory.h +++ b/arch/x86/include/asm/set_memory.h @@ -91,6 +91,14 @@ static inline int set_mce_nospec(unsigned long pfn) unsigned long decoy_addr; int rc; + /* + * If we are running as a guest, then the hypervisor + * will have removed all access from the page. So no + * point trying to make it uncacheable + */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + return 0; + /* * Mark the linear address as UC to make sure we don't log more * errors because of speculative access to the page. -- 2.21.1
| |