From: Borislav Petkov <bp@alien8.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
Linux NVDIMM <nvdimm@lists.linux.dev>,
Jane Chu <jane.chu@oracle.com>,
Luis Chamberlain <mcgrof@suse.com>
Subject: Re: [RFT PATCH] x86/pat: Fix set_mce_nospec() for pmem
Date: Thu, 30 Sep 2021 23:20:37 +0200 [thread overview]
Message-ID: <YVYqJZhBiTMXezZJ@zn.tnic> (raw)
In-Reply-To: <CAPcyv4jEby_ifqgPyfbSgouLJKseNRCCN=rcLHze_Y4X8BZC7g@mail.gmail.com>
On Thu, Sep 30, 2021 at 02:05:49PM -0700, Dan Williams wrote:
> I.e. it's fine
A lot of things are fine - question is, what makes sense and what makes
this thing as simple as required to be.
> if a DRAM page with a single cacheline error only gets marked UC.
> Speculation is disabled and the page allocator will still throw it
> away and never use it again.
Normal DRAM is poisoned as a whole page, as we established. So whatever
it is marked with - UC or NP - it probably doesn't matter. But since
the page won't be ever used, then that page is practically not present.
So I say, let's mark normal DRAM pages which have been poisoned as not
present and be done with it. Period.
> Similarly NP is fine for PMEM when the machine-check-registers
> indicate that the entire page is full of poison. The driver will
> record that and block any attempt to recover any data in that page.
So this is still kinda weird. We will mark it with either NP or UC but
the driver has some special knowledge how to tiptoe around poison. So
for simplicity, let's mark it with whatever fits best and be done with
it - driver can handle it just fine.
I hope you're cathing my drift: it doesn't really matter what's possible
wrt marking - it matters what the practical side of the whole thing
is wrt further page handling and recovery action. And we should do
here whatever does not impede that further page handling even if other
markings are possible.
Ok?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-09-30 21:20 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 1:01 [RFT PATCH] x86/pat: Fix set_mce_nospec() for pmem Dan Williams
2021-08-26 19:08 ` Dan Williams
2021-08-27 7:12 ` Jane Chu
2021-09-13 10:29 ` Borislav Petkov
2021-09-14 18:08 ` Dan Williams
2021-09-15 10:41 ` Borislav Petkov
2021-09-16 20:33 ` Dan Williams
2021-09-17 11:30 ` Borislav Petkov
2021-09-21 2:04 ` Dan Williams
2021-09-30 17:19 ` Borislav Petkov
2021-09-30 17:28 ` Luck, Tony
2021-09-30 19:30 ` Borislav Petkov
2021-09-30 19:41 ` Dan Williams
2021-09-30 19:44 ` Luck, Tony
2021-09-30 20:01 ` Borislav Petkov
2021-09-30 20:15 ` Luck, Tony
2021-09-30 20:32 ` Borislav Petkov
2021-09-30 20:39 ` Dan Williams
2021-09-30 20:54 ` Borislav Petkov
2021-09-30 21:05 ` Dan Williams
2021-09-30 21:20 ` Borislav Petkov [this message]
2021-09-30 21:41 ` Dan Williams
2021-09-30 22:35 ` Borislav Petkov
2021-09-30 22:44 ` Dan Williams
2021-10-01 10:41 ` Borislav Petkov
2021-10-01 0:43 ` Jane Chu
2021-10-01 2:02 ` Dan Williams
2021-10-01 10:50 ` Borislav Petkov
2021-10-01 16:52 ` Dan Williams
2021-10-01 18:11 ` Borislav Petkov
2021-10-01 18:29 ` Dan Williams
2021-10-02 10:17 ` Borislav Petkov
2021-11-11 0:06 ` Jane Chu
2021-11-12 0:30 ` Jane Chu
2021-11-12 0:51 ` Dan Williams
2021-11-12 17:57 ` Jane Chu
2021-11-12 19:24 ` Dan Williams
2021-11-12 22:35 ` Jane Chu
2021-11-12 22:50 ` Jane Chu
2021-11-12 23:08 ` Dan Williams
2021-11-13 5:50 ` Jane Chu
2021-11-13 20:47 ` Dan Williams
2021-11-18 19:03 ` Jane Chu
2021-11-25 0:16 ` Dan Williams
2021-11-30 23:00 ` Jane Chu
2021-09-30 18:15 ` Jane Chu
2021-09-30 19:11 ` Dan Williams
2021-09-30 21:23 ` Jane Chu
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=YVYqJZhBiTMXezZJ@zn.tnic \
--to=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=jane.chu@oracle.com \
--cc=mcgrof@suse.com \
--cc=nvdimm@lists.linux.dev \
--cc=tony.luck@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).