FAILED: patch "[PATCH] mm: invalidate hwpoison page cache page in fault path" failed to apply to 4.9-stable tree
Subsystems (3)
[email protected]
maintainerThe 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 <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From e53ac7374e64dede04d745ff0e70ff5048378d1f Mon Sep 17 00:00:00 2001
From: Rik van Riel <[email protected]>
Date: Tue, 22 Mar 2022 14:44:09 -0700
Subject: [PATCH] mm: invalidate hwpoison page cache page in fault path
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.
mm/memory.c +7 -2
@@ -3877,11 +3877,16 @@ static vm_fault_t __do_fault(struct vm_fault *vmf)return ret;if (unlikely (PageHWPoison (vmf->page))) { -if (ret &VM_FAULT_LOCKED ) +vm_fault_t 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); vmf->page =NULL ; -return VM_FAULT_HWPOISON ; +return poisonret; }if (unlikely (!(ret &VM_FAULT_LOCKED )))
Hi Greg,
Quoted 5 lines · On Fri, Apr 01, 2022 at 03:33:51PM +0200, [email protected] 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 <[email protected]>.
Here is the backport.
--
Regards
Sudip
From 37252de40b42bfaf259bf35b63f4e362b631844a Mon Sep 17 00:00:00 2001
From: Rik van Riel <[email protected]>
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.
--- mm/memory.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
mm/memory.c +7 -2
@@ -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 )))
Signature · 1 line
2.30.2