All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: "Zhuo, Qiuxu" <qiuxu.zhuo@intel.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"Luck, Tony" <tony.luck@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Lutomirski, Andy" <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>,
	"open list:HWPOISON MEMORY FAILURE HANDLING" <linux-mm@kvack.org>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] x86/mm: Forbid the zero page once it has uncorrectable errors
Date: Thu, 21 Apr 2022 10:50:44 +0200	[thread overview]
Message-ID: <022fe906-054d-43b4-14d4-a4c1cb7527af@redhat.com> (raw)
In-Reply-To: <DM8PR11MB566941C063EA44929147035E89F49@DM8PR11MB5669.namprd11.prod.outlook.com>

On 21.04.22 09:53, Zhuo, Qiuxu wrote:
>> From: Hansen, Dave <dave.hansen@intel.com>
>> ...
>> Subject: Re: [PATCH 1/1] x86/mm: Forbid the zero page once it has
>> uncorrectable errors
>> ...
>> There are lots of pages which are entirely fatal if they have uncorrectable errors.
>> On my laptop, if there were an error, there is a 0.00000596% chance it will be in
>> the zero page.
>>
>> Why is this worth special casing this one page?
> 
> Hi Dave,
> 
>    Yes, this is a rare problem. Just feel that the fix is simple, so post it here to see whether you'll consider it 😊.

Just some background information.

mm_forbids_zeropage() exists for the sole purpose of s390x/kvm not being
able to use the shared zeropage for a KVM guest because the storage keys
associated with the shared zeropage could result in trouble. So
s390x/kvm has to make sure that no shared zeropage
is mapped into the process.

See fa41ba0d08de ("s390/mm: avoid empty zero pages for KVM guests to
avoid postcopy hangs") for details.

@Christian

a) with keyless guests we could actually use the shared zeropage because
the guest cannot possibly enable storage keys, correct?

b) Why is there no mm_forbids_zeropage() check in mfill_zeropage_pte()?
Maybe I'm missing something, but looks like we can still place the
shared zeropage into a KVM guest via uffd.


In general, there are more place that will use the shared zeropage, most
notably, fs/dax.c  will place the shared zeropage for holes and would
still use it on x86-64. IIRC, s390x doesn't use it.

/proc/vmcore will map the zeropage to user space for areas that are not
RAM, so you could still stumble over it there and trigger a MCE.

Last but not least, the huge shared zeropage would suffer from similar
problems.


Also, I wonder if the generic code change in mm/memory-failure.c is
correct as it touches common code and you only mess with the x86
zeropage. But I did not look into the details.


So the code here at least isn't complete. So I'm not convinced this
change is worth it.


-- 
Thanks,

David / dhildenb


      reply	other threads:[~2022-04-21  8:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 21:00 [PATCH 1/1] x86/mm: Forbid the zero page once it has uncorrectable errors Qiuxu Zhuo
2022-04-20 13:39 ` Dave Hansen
2022-04-21  7:53   ` Zhuo, Qiuxu
2022-04-21  8:50     ` David Hildenbrand [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=022fe906-054d-43b4-14d4-a4c1cb7527af@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=peterz@infradead.org \
    --cc=qiuxu.zhuo@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.