From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: x86@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Darren Hart <dvhart@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v5] x86/mce: Avoid infinite loop for copy from user recovery
Date: Tue, 26 Jan 2021 12:03:14 +0100 [thread overview]
Message-ID: <20210126110314.GC6514@zn.tnic> (raw)
In-Reply-To: <20210125225509.GA7149@agluck-desk2.amr.corp.intel.com>
On Mon, Jan 25, 2021 at 02:55:09PM -0800, Luck, Tony wrote:
> And now I've changed it back to non-atomic (but keeping the
> slightly cleaner looking code style that I used for the atomic
> version). This one also works for thousands of injections and
> recoveries. Maybe take it now before it stops working again :-)
Hmm, so the only differences I see between your v4 and this are:
-@@ -1238,6 +1238,7 @@ static void __mc_scan_banks(struct mce *m, struct pt_regs *regs, struct mce *fin
+@@ -1238,6 +1238,9 @@ static void __mc_scan_banks(struct mce *m, struct pt_regs *regs, struct mce *fin
static void kill_me_now(struct callback_head *ch)
{
++ struct task_struct *p = container_of(ch, struct task_struct, mce_kill_me);
++
+ p->mce_count = 0;
force_sig(SIGBUS);
}
Could the container_of() macro have changed something?
Because we don't know yet (right?) why would it fail? Would it read
stale ->mce_count data? If so, then a barrier is missing somewhere.
Or what is the failure exactly?
Because if I take it now without us knowing what the issue is, it will
start failing somewhere - Murphy's our friend - and then we'll have to
deal with breaking people's boxes. Not fun.
The other difference is:
@@ -76,8 +71,10 @@ index 13d3f1cbda17..5460c146edb5 100644
- current->mce_kflags = m->kflags;
- current->mce_ripv = !!(m->mcgstatus & MCG_STATUS_RIPV);
- current->mce_whole_page = whole_page(m);
++ int count = ++current->mce_count;
++
+ /* First call, save all the details */
-+ if (current->mce_count++ == 0) {
++ if (count == 1) {
+ current->mce_addr = m->addr;
+ current->mce_kflags = m->kflags;
+ current->mce_ripv = !!(m->mcgstatus & MCG_STATUS_RIPV);
Hmm, a local variable and a pre-increment. Can that have an effect somehow?
> + /* Ten is likley overkill. Don't expect more than two faults before task_work() */
Typo: likely.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-01-26 12:20 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 22:22 [PATCH 0/2] Fix infinite machine check loop in futex_wait_setup() Tony Luck
2021-01-08 22:22 ` [PATCH 1/2] x86/mce: Avoid infinite loop for copy from user recovery Tony Luck
2021-01-08 22:22 ` [PATCH 2/2] futex, x86/mce: Avoid double machine checks Tony Luck
2021-01-08 22:47 ` Peter Zijlstra
2021-01-08 23:08 ` Luck, Tony
2021-01-08 23:14 ` Peter Zijlstra
2021-01-08 23:20 ` Luck, Tony
2021-01-11 21:44 ` [PATCH v2 0/3] Fix infinite machine check loop in futex_wait_setup() 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
2021-01-11 21:44 ` [PATCH v2 2/3] x86/mce: Add new return value to get_user() for machine check Tony Luck
2021-01-11 21:44 ` [PATCH v2 3/3] futex, x86/mce: Avoid double machine checks Tony Luck
2021-01-14 17:22 ` [PATCH v2 0/3] Fix infinite machine check loop in futex_wait_setup() Andy Lutomirski
2021-01-15 0:38 ` [PATCH v3] x86/mce: Avoid infinite loop for copy from user recovery Tony Luck
2021-01-15 15:27 ` Borislav Petkov
2021-01-15 19:34 ` Luck, Tony
2021-01-15 20:51 ` [PATCH v4] " Luck, Tony
2021-01-15 23:23 ` Luck, Tony
2021-01-19 10:56 ` Borislav Petkov
2021-01-19 23:57 ` Luck, Tony
2021-01-20 12:18 ` Borislav Petkov
2021-01-20 17:17 ` Luck, Tony
2021-01-21 21:09 ` Luck, Tony
2021-01-25 22:55 ` [PATCH v5] " Luck, Tony
2021-01-26 11:03 ` Borislav Petkov [this message]
2021-01-26 22:36 ` Luck, Tony
2021-01-28 17:57 ` Borislav Petkov
2021-02-01 18:58 ` Luck, Tony
2021-02-02 11:01 ` Borislav Petkov
2021-02-02 16:04 ` Luck, Tony
2021-02-02 21:06 ` Borislav Petkov
2021-02-02 22:12 ` Luck, Tony
2021-01-18 15:39 ` [PATCH v3] " Borislav Petkov
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=20210126110314.GC6514@zn.tnic \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=dvhart@infradead.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--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.