From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Jue Wang <juew@google.com>, Ding Hui <dinghui@sangfor.com.cn>,
naoya.horiguchi@nec.com, osalvador@suse.de,
Youquan Song <youquan.song@intel.com>,
huangcun@sangfor.com.cn, x86@kernel.org,
linux-edac@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] x86/mce: Avoid infinite loop for copy from user recovery
Date: Sun, 22 Aug 2021 16:36:46 +0200 [thread overview]
Message-ID: <YSJg/tCG5/YRSZIQ@zn.tnic> (raw)
In-Reply-To: <20210820202346.GA1623796@agluck-desk2.amr.corp.intel.com>
On Fri, Aug 20, 2021 at 01:23:46PM -0700, Luck, Tony wrote:
> To recover we need to have some other place to jump to (besides the
> normal extable error return ... which isn't working if we find ourselves
> in this situation) when we hit a fault covered by an extable entry. And
> also know how many machine checks is "normal" before taking the other path.
Hohumm, we're on the same page here.
...
> Bottom line is that I don't think this panic can actually happen unless
> there is some buggy kernel code that retries get_user() or copyin()
> indefinitely.
You know how such statements of "well, this should not really happen in
practice" get disproved by, well, practice. :-)
I guess we'll see anyway what actually happens in practice.
> Probably the same for the two different addresses case ... though I'm
> not 100% confident about that. There could be some ioctl() that peeks
> at two parts of a passed in structure, and the user might pass in a
> structure that spans across a page boundary with both pages poisoned.
> But that would only hit if the driver code ignored the failure of the
> first get_user() and blindly tried the second. So I'd count that as a
> critically bad driver bug.
Right.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-08-22 14:36 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-06 19:06 [PATCH 0/3] More machine check recovery fixes Tony Luck
2021-07-06 19:06 ` [PATCH 1/3] x86/mce: Change to not send SIGBUS error during copy from user Tony Luck
2021-07-06 19:06 ` [PATCH 2/3] x86/mce: Avoid infinite loop for copy from user recovery Tony Luck
2021-07-06 19:06 ` [PATCH 3/3] x86/mce: Drop copyin special case for #MC Tony Luck
2021-08-18 0:29 ` [PATCH v2 0/3] More machine check recovery fixes Tony Luck
2021-08-18 0:29 ` [PATCH v2 1/3] x86/mce: Avoid infinite loop for copy from user recovery Tony Luck
2021-08-20 17:31 ` Borislav Petkov
2021-08-20 18:59 ` Luck, Tony
2021-08-20 19:27 ` Borislav Petkov
2021-08-20 20:23 ` Luck, Tony
2021-08-21 4:51 ` Tony Luck
2021-08-21 21:51 ` Al Viro
2021-08-22 14:36 ` Borislav Petkov [this message]
2021-08-20 20:33 ` Luck, Tony
2021-08-22 14:46 ` Borislav Petkov
2021-08-23 15:24 ` Luck, Tony
2021-09-13 9:24 ` Borislav Petkov
2021-09-13 21:52 ` [PATCH v3] " Luck, Tony
2021-09-14 8:28 ` Borislav Petkov
2021-08-18 0:29 ` [PATCH v2 2/3] x86/mce: Change to not send SIGBUS error during copy from user Tony Luck
2021-09-21 7:52 ` [tip: ras/core] " tip-bot2 for Tony Luck
2021-08-18 0:29 ` [PATCH v2 3/3] x86/mce: Drop copyin special case for #MC Tony Luck
2021-09-20 9:13 ` Borislav Petkov
2021-09-20 16:18 ` Luck, Tony
2021-09-20 16:37 ` Borislav Petkov
2021-09-20 16:43 ` Luck, Tony
2021-09-21 7:52 ` [tip: ras/core] " tip-bot2 for Tony Luck
2021-08-18 16:14 ` [PATCH v2 0/3] More machine check recovery fixes Luck, Tony
-- strict thread matches above, loose matches on Subject: below --
2021-01-08 22:22 [PATCH 0/2] Fix infinite machine check loop in futex_wait_setup() Tony Luck
2021-01-11 21:44 ` [PATCH v2 0/3] " Tony Luck
2021-01-11 21:44 ` [PATCH v2 1/3] x86/mce: Avoid infinite loop for copy from user recovery Tony Luck
2021-01-11 22:11 ` Andy Lutomirski
2021-01-11 22:20 ` Luck, Tony
2021-01-12 17:00 ` Andy Lutomirski
2021-01-12 17:16 ` Luck, Tony
2021-01-12 17:21 ` Andy Lutomirski
2021-01-12 18:23 ` Luck, Tony
2021-01-12 18:57 ` Andy Lutomirski
2021-01-12 20:52 ` Luck, Tony
2021-01-12 22:04 ` Andy Lutomirski
2021-01-13 1:50 ` Luck, Tony
2021-01-13 4:15 ` Andy Lutomirski
2021-01-13 10:00 ` Borislav Petkov
2021-01-13 16:06 ` Luck, Tony
2021-01-13 16:19 ` Borislav Petkov
2021-01-13 16:32 ` Luck, Tony
2021-01-13 17:35 ` Borislav Petkov
2021-01-14 20:22 ` Borislav Petkov
2021-01-14 21:05 ` Luck, Tony
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=YSJg/tCG5/YRSZIQ@zn.tnic \
--to=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=linux-mm@kvack.org \
--cc=naoya.horiguchi@nec.com \
--cc=osalvador@suse.de \
--cc=tony.luck@intel.com \
--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.