From: "Luck, Tony" <tony.luck@intel.com>
To: David Laight <David.Laight@ACULAB.COM>,
Shuai Xue <xueshuai@linux.alibaba.com>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>,
Andrew Morton <akpm@linux-foundation.org>,
Miaohe Lin <linmiaohe@huawei.com>,
"Matthew Wilcox" <willy@infradead.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: RE: [PATCH v2] mm, hwpoison: Try to recover from copy-on write faults
Date: Fri, 21 Oct 2022 04:41:04 +0000 [thread overview]
Message-ID: <SJ1PR11MB6083624E288992BFA902CC8CFC2D9@SJ1PR11MB6083.namprd11.prod.outlook.com> (raw)
In-Reply-To: <1643d19d795b4a8084228eab66a7db9f@AcuMS.aculab.com>
>> When we do return to user mode the task is going to be busy servicing
>> a SIGBUS ... so shouldn't try to touch the poison page before the
>> memory_failure() called by the worker thread cleans things up.
>
> What about an RT process on a busy system?
> The worker threads are pretty low priority.
Most tasks don't have a SIGBUS handler ... so they just die without possibility of accessing poison
If this task DOES have a SIGBUS handler, and that for some bizarre reason just does a "return"
so the task jumps back to the instruction that cause the COW then there is a 63/64
likelihood that it is touching a different cache line from the poisoned one.
In the 1/64 case ... its probably a simple store (since there was a COW, we know it was trying to
modify the page) ... so won't generate another machine check (those only happen for reads).
But maybe it is some RMW instruction ... then, if all the above options didn't happen ... we
could get another machine check from the same address. But then we just follow the usual
recovery path.
-Tony
next prev parent reply other threads:[~2022-10-21 4:41 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 23:42 [RFC PATCH] mm, hwpoison: Recover from copy-on-write machine checks Tony Luck
2022-10-18 8:43 ` HORIGUCHI NAOYA(堀口 直也)
2022-10-18 17:52 ` Luck, Tony
2022-10-19 17:08 ` [PATCH v2] mm, hwpoison: Try to recover from copy-on write faults Tony Luck
2022-10-19 17:45 ` Dan Williams
2022-10-19 20:30 ` Luck, Tony
2022-10-20 1:57 ` Shuai Xue
2022-10-20 20:05 ` Tony Luck
2022-10-21 1:38 ` Miaohe Lin
2022-10-21 3:57 ` Luck, Tony
2022-10-21 1:52 ` Shuai Xue
2022-10-21 4:08 ` Tony Luck
2022-10-21 4:11 ` David Laight
2022-10-21 4:41 ` Luck, Tony [this message]
2022-10-21 9:29 ` Shuai Xue
2022-10-21 16:30 ` Luck, Tony
2022-10-23 15:04 ` Shuai Xue
2022-10-21 6:57 ` Shuai Xue
2022-10-21 20:01 ` [PATCH v3 0/2] Copy-on-write poison recovery Tony Luck
2022-10-21 20:01 ` [PATCH v3 1/2] mm, hwpoison: Try to recover from copy-on write faults Tony Luck
2022-10-25 5:46 ` HORIGUCHI NAOYA(堀口 直也)
2022-10-28 2:11 ` Miaohe Lin
2022-10-28 16:09 ` Luck, Tony
2022-11-02 14:27 ` Alexander Potapenko
2022-11-02 14:30 ` Alexander Potapenko
2022-10-21 20:01 ` [PATCH v3 2/2] mm, hwpoison: When copy-on-write hits poison, take page offline Tony Luck
2022-10-28 2:28 ` Miaohe Lin
2022-10-28 16:13 ` Luck, Tony
2022-10-29 1:55 ` Miaohe Lin
2022-10-23 15:52 ` [PATCH v3 0/2] Copy-on-write poison recovery Shuai Xue
2022-10-26 5:19 ` Shuai Xue
2022-10-31 20:10 ` [PATCH v4 " Tony Luck
2022-10-31 20:10 ` [PATCH v4 1/2] mm, hwpoison: Try to recover from copy-on write faults Tony Luck
2022-10-31 20:10 ` [PATCH v4 2/2] mm, hwpoison: When copy-on-write hits poison, take page offline Tony Luck
2023-05-18 21:49 ` Jane Chu
2023-05-18 22:10 ` Luck, Tony
2023-05-19 7:28 ` Greg Kroah-Hartman
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=SJ1PR11MB6083624E288992BFA902CC8CFC2D9@SJ1PR11MB6083.namprd11.prod.outlook.com \
--to=tony.luck@intel.com \
--cc=David.Laight@ACULAB.COM \
--cc=akpm@linux-foundation.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dan.j.williams@intel.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=naoya.horiguchi@nec.com \
--cc=npiggin@gmail.com \
--cc=willy@infradead.org \
--cc=xueshuai@linux.alibaba.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