From: "Luck, Tony" <tony.luck@intel.com>
To: Jue Wang <juew@google.com>
Cc: "Borislav Petkov" <bp@alien8.de>,
dinghui@sangfor.com.cn, huangcun@sangfor.com.cn,
linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
"HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>,
"Oscar Salvador" <osalvador@suse.de>, x86 <x86@kernel.org>,
"Song, Youquan" <youquan.song@intel.com>
Subject: Re: [PATCH 2/3] x86/mce: Avoid infinite loop for copy from user recovery
Date: Thu, 22 Jul 2021 17:14:36 -0700 [thread overview]
Message-ID: <20210723001436.GA1460637@agluck-desk2.amr.corp.intel.com> (raw)
In-Reply-To: <CAPcxDJ6bB7GEhTq9fkHuT4chRTUk_s-crci=nh+COCwAzMP8Yw@mail.gmail.com>
On Thu, Jul 22, 2021 at 04:30:44PM -0700, Jue Wang wrote:
> I think the challenge being the uncorrectable errors are essentially
> random. It's
> just a matter of time for >1 UC errors to show up in sequential kernel accesses.
>
> It's easy to create such cases with artificial error injections.
>
> I suspect we want to design this part of the kernel to be able to handle generic
> cases?
Remember that:
1) These errors are all in application memory
2) We reset the count every time we get into the task_work function that
will return to user
So the multiple error scenario here is one where we hit errors
on different user pages on a single trip into the kernel.
Hitting the same page is easy. The kernel has places where it
can hit poison with page faults disabled, and it then enables
page faults and retries the same access, and hits poison again.
I'm not aware of, nor expecting to find, places where the kernel
tries to access user address A and hits poison, and then tries to
access user address B (without returrning to user between access
A and access B).
-Tony
next prev parent reply other threads:[~2021-07-23 0:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-22 13:54 [PATCH 2/3] x86/mce: Avoid infinite loop for copy from user recovery Jue Wang
2021-07-22 15:19 ` Luck, Tony
2021-07-22 23:30 ` Jue Wang
2021-07-23 0:14 ` Luck, Tony [this message]
2021-07-23 3:47 ` Jue Wang
2021-07-23 4:01 ` Luck, Tony
2021-07-23 4:16 ` Jue Wang
2021-07-23 14:47 ` Luck, Tony
-- strict thread matches above, loose matches on Subject: below --
2021-07-31 6:30 Jue Wang
2021-07-31 20:43 ` Luck, Tony
2021-08-02 15:29 ` Jue Wang
2021-07-06 19:06 [PATCH 0/3] More machine check recovery fixes Tony Luck
2021-07-06 19:06 ` [PATCH 2/3] x86/mce: Avoid infinite loop for copy from user recovery Tony Luck
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=20210723001436.GA1460637@agluck-desk2.amr.corp.intel.com \
--to=tony.luck@intel.com \
--cc=bp@alien8.de \
--cc=dinghui@sangfor.com.cn \
--cc=huangcun@sangfor.com.cn \
--cc=juew@google.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=naoya.horiguchi@nec.com \
--cc=osalvador@suse.de \
--cc=x86@kernel.org \
--cc=youquan.song@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).