From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
To: gregkh@linuxfoundation.org
Cc: riel@surriel.com, akpm@linux-foundation.org, hannes@cmpxchg.org,
jhubbard@nvidia.com, linmiaohe@huawei.com, mgorman@suse.de,
naoya.horiguchi@nec.com, osalvador@suse.de,
stable@vger.kernel.org, torvalds@linux-foundation.org,
willy@infradead.org
Subject: Re: FAILED: patch "[PATCH] mm: invalidate hwpoison page cache page in fault path" failed to apply to 4.9-stable tree
Date: Wed, 13 Jul 2022 21:13:57 +0100 [thread overview]
Message-ID: <Ys8nhREHBqv64dxR@debian> (raw)
In-Reply-To: <1648820031141132@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
Hi Greg,
On Fri, Apr 01, 2022 at 03:33:51PM +0200, gregkh@linuxfoundation.org wrote:
>
> The patch below does not apply to the 4.9-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
Here is the backport.
--
Regards
Sudip
[-- Attachment #2: 0001-mm-invalidate-hwpoison-page-cache-page-in-fault-path.patch --]
[-- Type: text/x-diff, Size: 2529 bytes --]
From 37252de40b42bfaf259bf35b63f4e362b631844a Mon Sep 17 00:00:00 2001
From: Rik van Riel <riel@surriel.com>
Date: Tue, 22 Mar 2022 14:44:09 -0700
Subject: [PATCH] mm: invalidate hwpoison page cache page in fault path
commit e53ac7374e64dede04d745ff0e70ff5048378d1f upstream.
Sometimes the page offlining code can leave behind a hwpoisoned clean
page cache page. This can lead to programs being killed over and over
and over again as they fault in the hwpoisoned page, get killed, and
then get re-spawned by whatever wanted to run them.
This is particularly embarrassing when the page was offlined due to
having too many corrected memory errors. Now we are killing tasks due
to them trying to access memory that probably isn't even corrupted.
This problem can be avoided by invalidating the page from the page fault
handler, which already has a branch for dealing with these kinds of
pages. With this patch we simply pretend the page fault was successful
if the page was invalidated, return to userspace, incur another page
fault, read in the file from disk (to a new memory page), and then
everything works again.
Link: https://lkml.kernel.org/r/20220212213740.423efcea@imladris.surriel.com
Signed-off-by: Rik van Riel <riel@surriel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sudip: use int instead of vm_fault_t and adjust context]
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
---
mm/memory.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 1b31cdce936e9..36d46e19df960 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2891,10 +2891,15 @@ static int __do_fault(struct fault_env *fe, pgoff_t pgoff,
}
if (unlikely(PageHWPoison(vmf.page))) {
- if (ret & VM_FAULT_LOCKED)
+ int poisonret = VM_FAULT_HWPOISON;
+ if (ret & VM_FAULT_LOCKED) {
+ /* Retry if a clean page was removed from the cache. */
+ if (invalidate_inode_page(vmf.page))
+ poisonret = 0;
unlock_page(vmf.page);
+ }
put_page(vmf.page);
- return VM_FAULT_HWPOISON;
+ return poisonret;
}
if (unlikely(!(ret & VM_FAULT_LOCKED)))
--
2.30.2
prev parent reply other threads:[~2022-07-13 20:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-01 13:33 FAILED: patch "[PATCH] mm: invalidate hwpoison page cache page in fault path" failed to apply to 4.9-stable tree gregkh
2022-07-13 20:13 ` Sudip Mukherjee [this message]
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=Ys8nhREHBqv64dxR@debian \
--to=sudipm.mukherjee@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=jhubbard@nvidia.com \
--cc=linmiaohe@huawei.com \
--cc=mgorman@suse.de \
--cc=naoya.horiguchi@nec.com \
--cc=osalvador@suse.de \
--cc=riel@surriel.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.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 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).