From: "Luck, Tony" <tony.luck@intel.com>
To: Jue Wang <juew@google.com>
Cc: "Borislav Petkov" <bp@alien8.de>,
"dinghui@sangfor.com.cn" <dinghui@sangfor.com.cn>,
"huangcun@sangfor.com.cn" <huangcun@sangfor.com.cn>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@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: Sat, 31 Jul 2021 20:43:13 +0000 [thread overview]
Message-ID: <fc4d994b02f643d480647edc4f2a7a29@intel.com> (raw)
In-Reply-To: <CAPcxDJ6qnrkuckxm6KkoONZZh5Q-H3-CkFiWq627p5OF3GKJ4Q@mail.gmail.com>
> After cherry picking patch 1 & 2, I saw the following with 2 UC errors injected
> into the user space buffer passed into write(2), as expected:
>
> [ 287.994754] Kernel panic - not syncing: Machine checks to different
> user pages
Interesting. What are the offsets of the two injected errors in your test (both
w.r.t. the start of the buffer, and within a page).
> The kernel tested with has its x86/mce and mm/memory-failure aligned with
> upstream till around 2020/11.
>
> Is there any other patch that I have missed to the write syscall etc?
There is a long series of patches from Al Viro to lib/iov_iter.c that are maybe
also relevent in making the kernel copy from user stop at the first poison
address in the buffer.
-Tony
next prev parent reply other threads:[~2021-07-31 20:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-31 6:30 [PATCH 2/3] x86/mce: Avoid infinite loop for copy from user recovery Jue Wang
2021-07-31 20:43 ` Luck, Tony [this message]
2021-08-02 15:29 ` Jue Wang
-- strict thread matches above, loose matches on Subject: below --
2021-07-22 13:54 Jue Wang
2021-07-22 15:19 ` Luck, Tony
2021-07-22 23:30 ` Jue Wang
2021-07-23 0:14 ` Luck, Tony
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
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=fc4d994b02f643d480647edc4f2a7a29@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 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.