hwpoison, shmem: fix data lost issue for 5.15.y

DISCUSSION Naoya Horiguchi 5 participants 13 messages Nov 14, 2022 – Nov 24, 2022

Subsystems (4)

Stable branch Memory management HugeTLB HWPoison memory failure handling

lore

Share & tools

lore

Naoya Horiguchi

author

2022-11-14 13:14 UTC #0 lore raw

Hi,

I'd like to request the follow commits to be backported to 5.15.y.

- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")

These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.

Thanks,
Naoya Horiguchi

Greg KH

maintainer

2022-11-14 16:11 UTC #1 lore raw

Quoted 11 lines · Naoya Horiguchi

Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.

And have you tested that these all apply properly (and in which order?) and work correctly?

thanks,

greg k-h

Naoya Horiguchi

author

2022-11-14 22:39 UTC #2 lore raw

Quoted 9 lines · Greg KH

Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")

Quoted 5 lines

Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)

Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).

Quoted 1 line

and work correctly?

Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.

Thanks,
Naoya Horiguchi

Mike Kravetz

2022-11-14 22:54 UTC #3 lore raw

Quoted 16 lines · Naoya Horiguchi

Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)

Quoted 8 lines

Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.

Hi Naoya,

Just curious if you have plans to do backports for earlier releases?

If not, I can start that effort. We have seen data loss/corruption because of
this on a 4.14 based release. So, I would go at least that far back.

Signature · 1 line

Mike Kravetz

HORIGUCHI NAOYA(堀口直也)

2022-11-15 01:16 UTC #4 lore raw

Quoted 21 lines · Mike Kravetz

Quoted 20 lines · Naoya Horiguchi
Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)
Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.
Hi Naoya,
Just curious if you have plans to do backports for earlier releases?

I didn't have a clear plan. I just thought that we should backport to earlier kernels if someone want and the patches are applicable easily enough and well-tested.

Quoted 3 lines

If not, I can start that effort. We have seen data loss/corruption because of
this on a 4.14 based release. So, I would go at least that far back.

Thank you for raising hand, that's really helpful.

Maybe dd0f230a0a80 ("[PATCH] hugetlbfs: don't delete error page from pagecbache") should be considered to backport together, because it's the similar issue and reported (a while ago) to fail to backport. dd0f230a0a80 does not apply cleanly on top of 5.15.78 + the above 3 patches. So I need check more and will update my current proposal for 5.15.y.

Thanks,
Naoya Horiguchi

Mike Kravetz

2022-11-15 01:31 UTC #5 lore raw

Quoted 36 lines · HORIGUCHI NAOYA(堀口直也)

Quoted 21 lines · Mike Kravetz
Quoted 20 lines · Naoya Horiguchi
Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)
Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.
Hi Naoya,
Just curious if you have plans to do backports for earlier releases?
I didn't have a clear plan. I just thought that we should backport to earlier kernels if someone want and the patches are applicable easily enough and well-tested.
Quoted 1 line

Quoted 8 lines

Quoted 2 lines
If not, I can start that effort. We have seen data loss/corruption because of
this on a 4.14 based release. So, I would go at least that far back.
Thank you for raising hand, that's really helpful.
Maybe dd0f230a0a80 ("[PATCH] hugetlbfs: don't delete error page from pagecbache") should be considered to backport together, because it's the similar issue and reported (a while ago) to fail to backport.

Since dd0f230a0a80 was marked for backports, Greg's automation flags it as FAILED due to conflicts in earlier releases. I am not sure if James has a plan to do backports for dd0f230a0a80. Again, this is also something I would help with due to real customer issues.

Signature · 1 line

Mike Kravetz

Quoted 5 lines

dd0f230a0a80 does not apply cleanly on top of 5.15.78 + the above 3 patches. So I need check more and will update my current proposal for 5.15.y.
Thanks,
Naoya Horiguchi

Naoya Horiguchi

author Reviewed-by Mike Kravetz Reviewed-by Tested-by Reviewed-by Yang Shi

2022-11-15 06:39 UTC #6 lore raw

Quoted 37 lines · Mike Kravetz

Quoted 36 lines · HORIGUCHI NAOYA(堀口直也)
Quoted 21 lines · Mike Kravetz
Quoted 20 lines · Naoya Horiguchi
Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)
Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.
Hi Naoya,
Just curious if you have plans to do backports for earlier releases?
I didn't have a clear plan. I just thought that we should backport to earlier kernels if someone want and the patches are applicable easily enough and well-tested.
Quoted 1 line

Quoted 6 lines

Quoted 6 lines
Quoted 2 lines
If not, I can start that effort. We have seen data loss/corruption because of
this on a 4.14 based release. So, I would go at least that far back.
Thank you for raising hand, that's really helpful.
Maybe dd0f230a0a80 ("[PATCH] hugetlbfs: don't delete error page from

# I meant 8625147cafaa, sorry if the wrong commit ID confused you.

I tested with 8625147cafaa too, and it made hugetlb-related testcases passed.

Quoted 7 lines

Quoted 2 lines
pagecbache") should be considered to backport together, because it's the similar issue and reported (a while ago) to fail to backport.
Since dd0f230a0a80 was marked for backports, Greg's automation flags it as FAILED due to conflicts in earlier releases. I am not sure if James has a plan to do backports for dd0f230a0a80. Again, this is also something I would help with due to real customer issues.

OK, so I do want 8625147cafaa to be merged to stable.
Another reason why I addressed 8625147cafaa here is that this patch depends on the code handling "extra_pins" (given by dd0f230a0a80) and it's simpler to handle together.

We need to slightly modify 8625147cafaa to apply to 5.15.y. So in summary, my updated suggestion for 5.15.y is like below:

- [1/4] cherry-pick dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- [2/4] cherry-pick 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- [3/4] cherry-pick a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
- [4/4] apply the following patch (as a modified version of 8625147cafaa)

Thanks,
Naoya Horiguchi
---
From bdd88699d8ba6907e0815608482f8c0e2170982d Mon Sep 17 00:00:00 2001
From: James Houghton <[email protected]>
Date: Tue, 15 Nov 2022 15:20:51 +0900
Subject: [PATCH] hugetlbfs: don't delete error page from pagecache

commit 8625147cafaa9ba74713d682f5185eb62cb2aedb upstream.

This change is very similar to the change that was made for shmem [1], and it solves the same problem but for HugeTLBFS instead.

Currently, when poison is found in a HugeTLB page, the page is removed from the page cache. That means that attempting to map or read that hugepage in the future will result in a new hugepage being allocated instead of notifying the user that the page was poisoned. As [1] states, this is effectively memory corruption.

The fix is to leave the page in the page cache. If the user attempts to use a poisoned HugeTLB page with a syscall, the syscall will fail with EIO, the same error code that shmem uses. For attempts to map the page, the thread will get a BUS_MCEERR_AR SIGBUS.

[1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")

Although there's a conflict in hugetlbfs_error_remove_page() when backporting to stable tree, the resolution is almost trivial (just removing conflicting lines in the function).

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by James Houghton <[email protected]>

Reviewed-by Mike Kravetz <[email protected]>

Reviewed-by Naoya Horiguchi <[email protected]>

Tested-by Naoya Horiguchi <[email protected]>

Reviewed-by Yang Shi <[email protected]>

Cc Axel Rasmussen <[email protected]>

Cc James Houghton <[email protected]>

Cc Miaohe Lin <[email protected]>

Cc Muchun Song <[email protected]>

Cc <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

---
 fs/hugetlbfs/inode.c | 13 ++++++-------
 mm/hugetlb.c         |  4 ++++
 mm/memory-failure.c  |  5 ++++-
 3 files changed, 14 insertions(+), 8 deletions(-)

fs/hugetlbfs/inode.c +6 -7

index d74a49b188c2..be8deec29ebe 100644
@@ -361,6 +361,12 @@ static ssize_t hugetlbfs_read_iter(struct kiocb *iocb, struct iov_iter *to)
 		} else {
 			unlock_page(page);
 
+			if (PageHWPoison(page)) {
+				put_page(page);
+				retval = -EIO;
+				break;
+			}
+
 			/*
 			 * We have the page, copy it to user space buffer.
 			 */

@@ -984,13 +990,6 @@ static int hugetlbfs_migrate_page(struct address_space *mapping,
 static int hugetlbfs_error_remove_page(struct address_space *mapping,
 				struct page *page)
 {
-	struct inode *inode = mapping->host;
-	pgoff_t index = page->index;
-
-	remove_huge_page(page);
-	if (unlikely(hugetlb_unreserve_pages(inode, index, index + 1, 1)))
-		hugetlb_fix_reserve_counts(inode);
-
 	return 0;
 }

mm/hugetlb.c +4 -0

index dbb63ec3b5fa..e7bd42f23667 100644
@@ -5350,6 +5350,10 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm,
 	ptl = huge_pte_lockptr(h, dst_mm, dst_pte);
 	spin_lock(ptl);
 
+	ret = -EIO;
+	if (PageHWPoison(page))
+		goto out_release_unlock;
+
 	/*
 	 * Recheck the i_size after holding PT lock to make sure not
 	 * to leave any page mapped (as page_mapped()) beyond the end

mm/memory-failure.c +4 -1

index 85b1a77e3a99..2ad0f4580091 100644
@@ -1040,6 +1040,7 @@ static int me_huge_page(struct page_state *ps, struct page *p)
 	int res;
 	struct page *hpage = compound_head(p);
 	struct address_space *mapping;
+	bool extra_pins = false;
 
 	if (!PageHuge(hpage))
 		return MF_DELAYED;

@@ -1047,6 +1048,8 @@ static int me_huge_page(struct page_state *ps, struct page *p)
 	mapping = page_mapping(hpage);
 	if (mapping) {
 		res = truncate_error_page(hpage, page_to_pfn(p), mapping);
+		/* The page is kept in page cache. */
+		extra_pins = true;
 		unlock_page(hpage);
 	} else {
 		res = MF_FAILED;

@@ -1064,7 +1067,7 @@ static int me_huge_page(struct page_state *ps, struct page *p)
 		}
 	}
 
-	if (has_extra_refcount(ps, p, false))
+	if (has_extra_refcount(ps, p, extra_pins))
 		res = MF_FAILED;
 
 	return res;

Signature · 1 line

2.37.3.518.g79f2338b37

Mike Kravetz

2022-11-16 03:49 UTC #7 lore raw

Quoted 49 lines · Naoya Horiguchi

Quoted 37 lines · Mike Kravetz
Quoted 36 lines · HORIGUCHI NAOYA(堀口直也)
Quoted 21 lines · Mike Kravetz
Quoted 20 lines · Naoya Horiguchi
Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)
Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.
Hi Naoya,
Just curious if you have plans to do backports for earlier releases?
I didn't have a clear plan. I just thought that we should backport to earlier kernels if someone want and the patches are applicable easily enough and well-tested.
Quoted 1 line
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
If not, I can start that effort. We have seen data loss/corruption because of
this on a 4.14 based release. So, I would go at least that far back.
Thank you for raising hand, that's really helpful.
Maybe dd0f230a0a80 ("[PATCH] hugetlbfs: don't delete error page from
# I meant 8625147cafaa, sorry if the wrong commit ID confused you.
I tested with 8625147cafaa too, and it made hugetlb-related testcases passed.

<snip>

Quoted 7 lines

We need to slightly modify 8625147cafaa to apply to 5.15.y. So in summary, my updated suggestion for 5.15.y is like below:
- [1/4] cherry-pick dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- [2/4] cherry-pick 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- [3/4] cherry-pick a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
- [4/4] apply the following patch (as a modified version of 8625147cafaa)

Hi Naoya,

Just curious, do you have automated tests for this? I wanted test backports to each stable release. I could manually test, but that would be a bit involved and was hoping you had something automated.

Signature · 1 line

Mike Kravetz

Naoya Horiguchi

author

2022-11-16 23:58 UTC #8 lore raw

Quoted 59 lines · Mike Kravetz

Quoted 49 lines · Naoya Horiguchi
Quoted 37 lines · Mike Kravetz
Quoted 36 lines · HORIGUCHI NAOYA(堀口直也)
Quoted 21 lines · Mike Kravetz
Quoted 20 lines · Naoya Horiguchi
Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)
Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.
Hi Naoya,
Just curious if you have plans to do backports for earlier releases?
I didn't have a clear plan. I just thought that we should backport to earlier kernels if someone want and the patches are applicable easily enough and well-tested.
Quoted 1 line
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
If not, I can start that effort. We have seen data loss/corruption because of
this on a 4.14 based release. So, I would go at least that far back.
Thank you for raising hand, that's really helpful.
Maybe dd0f230a0a80 ("[PATCH] hugetlbfs: don't delete error page from
# I meant 8625147cafaa, sorry if the wrong commit ID confused you.
I tested with 8625147cafaa too, and it made hugetlb-related testcases passed.
<snip>
Quoted 7 lines
We need to slightly modify 8625147cafaa to apply to 5.15.y. So in summary, my updated suggestion for 5.15.y is like below:
- [1/4] cherry-pick dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- [2/4] cherry-pick 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- [3/4] cherry-pick a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
- [4/4] apply the following patch (as a modified version of 8625147cafaa)

Quoted 5 lines

Hi Naoya,
Just curious, do you have automated tests for this? I wanted test backports to each stable release. I could manually test, but that would be a bit involved and was hoping you had something automated.

Yes, related testcases are available on https://github.com/nhoriguchi/mm_regression.
You can run them by the following steps:

  $ git clone https://github.com/nhoriguchi/mm_regression.
  $ cd mm_regression

# Check that your testing server meets the prerequisite # https://github.com/nhoriguchi/mm_regression#prerequisite

  $ make
  ...
  # Compiler might show errors but that's OK because all
  # files are not needed to run relevant testcases.

  $ bash run.sh prepare debug

# List the testcases in work/debug/recipelist like below:

  $ cat work/debug/recipelist
  mm/hwpoison/shmem_link/link-hard.auto3
  mm/hwpoison/shmem_link/link-sym.auto3
  mm/hwpoison/shmem_rw/thp-always.auto3
  mm/hwpoison/shmem_rw/thp-never.auto3

  $ bash run.sh project run

Thanks,
Naoya Horiguchi

Mike Kravetz

2022-11-23 01:05 UTC #9 lore raw

In reply to HORIGUCHI NAOYA(堀口直也)

Quoted 39 lines · HORIGUCHI NAOYA(堀口直也)

Quoted 21 lines · Mike Kravetz
Quoted 20 lines · Naoya Horiguchi
Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)
Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.
Hi Naoya,
Just curious if you have plans to do backports for earlier releases?
I didn't have a clear plan. I just thought that we should backport to earlier kernels if someone want and the patches are applicable easily enough and well-tested.
Quoted 3 lines
If not, I can start that effort. We have seen data loss/corruption because of
this on a 4.14 based release. So, I would go at least that far back.

Quoted 7 lines

Thank you for raising hand, that's really helpful.
Maybe dd0f230a0a80 ("[PATCH] hugetlbfs: don't delete error page from pagecbache") should be considered to backport together, because it's the similar issue and reported (a while ago) to fail to backport. dd0f230a0a80 does not apply cleanly on top of 5.15.78 + the above 3 patches. So I need check more and will update my current proposal for 5.15.y.

When working with 5.10.y, I noticed that commit eac96c3efdb5 ("mm: filemap:
check if THP has hwpoisoned subpage for PMD page fault") as well as the prereq commit c7cb42e94473 ("mm: hwpoison: remove the unnecessary THP check") were not backported to 5.10.y. Without those patches, THP testing will fail.

Naoya and Yang Shi, does that sound right?

I have backports for those as well but want to check if you think anything else is needed.

Signature · 1 line

Mike Kravetz

Yang Shi

2022-11-23 18:54 UTC #10 lore raw

Quoted 49 lines · Mike Kravetz

Quoted 39 lines · HORIGUCHI NAOYA(堀口直也)
Quoted 21 lines · Mike Kravetz
Quoted 20 lines · Naoya Horiguchi
Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)
Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.
Hi Naoya,
Just curious if you have plans to do backports for earlier releases?
I didn't have a clear plan. I just thought that we should backport to earlier kernels if someone want and the patches are applicable easily enough and well-tested.
Quoted 3 lines
If not, I can start that effort. We have seen data loss/corruption because of
this on a 4.14 based release. So, I would go at least that far back.
Quoted 7 lines
Thank you for raising hand, that's really helpful.
Maybe dd0f230a0a80 ("[PATCH] hugetlbfs: don't delete error page from pagecbache") should be considered to backport together, because it's the similar issue and reported (a while ago) to fail to backport. dd0f230a0a80 does not apply cleanly on top of 5.15.78 + the above 3 patches. So I need check more and will update my current proposal for 5.15.y.

Quoted 7 lines

When working with 5.10.y, I noticed that commit eac96c3efdb5 ("mm: filemap:
check if THP has hwpoisoned subpage for PMD page fault") as well as the prereq commit c7cb42e94473 ("mm: hwpoison: remove the unnecessary THP check") were not backported to 5.10.y. Without those patches, THP testing will fail.
Naoya and Yang Shi, does that sound right?

Yes, since the hwpoisoned THP will be kept in page cache so the page fault may happen on it again, without that commit the page fault won't return -EHWPOISON if I remember correctly.

Quoted 3 lines

I have backports for those as well but want to check if you think anything else is needed.

Thanks for backporting them. No more fix is needed AFAICT.

Quoted 2 lines

--
Mike Kravetz

Naoya Horiguchi

author

2022-11-24 03:03 UTC #11 lore raw

Quoted 63 lines · Yang Shi

Quoted 49 lines · Mike Kravetz
Quoted 39 lines · HORIGUCHI NAOYA(堀口直也)
Quoted 21 lines · Mike Kravetz
Quoted 20 lines · Naoya Horiguchi
Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)
Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.
Hi Naoya,
Just curious if you have plans to do backports for earlier releases?
I didn't have a clear plan. I just thought that we should backport to earlier kernels if someone want and the patches are applicable easily enough and well-tested.
Quoted 3 lines
If not, I can start that effort. We have seen data loss/corruption because of
this on a 4.14 based release. So, I would go at least that far back.
Quoted 7 lines
Thank you for raising hand, that's really helpful.
Maybe dd0f230a0a80 ("[PATCH] hugetlbfs: don't delete error page from pagecbache") should be considered to backport together, because it's the similar issue and reported (a while ago) to fail to backport. dd0f230a0a80 does not apply cleanly on top of 5.15.78 + the above 3 patches. So I need check more and will update my current proposal for 5.15.y.
Quoted 7 lines
When working with 5.10.y, I noticed that commit eac96c3efdb5 ("mm: filemap:
check if THP has hwpoisoned subpage for PMD page fault") as well as the prereq commit c7cb42e94473 ("mm: hwpoison: remove the unnecessary THP check") were not backported to 5.10.y. Without those patches, THP testing will fail.
Naoya and Yang Shi, does that sound right?
Yes, since the hwpoisoned THP will be kept in page cache so the page fault may happen on it again, without that commit the page fault won't return -EHWPOISON if I remember correctly.
Quoted 1 line

Quoted 4 lines

Quoted 2 lines
I have backports for those as well but want to check if you think anything else is needed.
Thanks for backporting them. No more fix is needed AFAICT.

I agree with Yang. There seems no other commit related to current pagecache problem but not backported yet.

Thanks,
Naoya Horiguchi

Greg KH

maintainer

2022-11-16 09:17 UTC #12 lore raw

In reply to Naoya Horiguchi

Quoted 16 lines · Naoya Horiguchi

Quoted 9 lines · Greg KH
Quoted 8 lines · Naoya Horiguchi
Hi,
I'd like to request the follow commits to be backported to 5.15.y.
- dd0f230a0a80 ("mm: hwpoison: refactor refcount check handling")
- 4966455d9100 ("mm: hwpoison: handle non-anonymous THP correctly")
- a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Quoted 5 lines
Quoted 3 lines
These patches fixed a data lost issue by preventing shmem pagecache from being removed by memory error. These were not tagged for stable originally, but that's revisited recently.
And have you tested that these all apply properly (and in which order?)

Quoted 8 lines

Yes, I've checked that these cleanly apply (without any change) on 5.15.78 in the above order (i.e. dd0f23 is first, 496645 comes next, then a76054).
Quoted 1 line
and work correctly?
Yes, I ran related testcases in my test suite, and their status changed FAIL to PASS with these patches.

Great, all now queued up, thanks.

greg k-h