linux-stable.git/mm/memory-failure.c, branch linux-6.2.y

mm/hwpoison: convert TTU_IGNORE_HWPOISON to TTU_HWPOISON

2023-03-10T08:29:48+00:00

commit 6da6b1d4a7df8c35770186b53ef65d388398e139 upstream.

After a memory error happens on a clean folio, a process unexpectedly
receives SIGBUS when it accesses the error page.  This SIGBUS killing is
pointless and simply degrades the level of RAS of the system, because the
clean folio can be dropped without any data lost on memory error handling
as we do for a clean pagecache.

When memory_failure() is called on a clean folio, try_to_unmap() is called
twice (one from split_huge_page() and one from hwpoison_user_mappings()).
The root cause of the issue is that pte conversion to hwpoisoned entry is
now done in the first call of try_to_unmap() because PageHWPoison is
already set at this point, while it's actually expected to be done in the
second call.  This behavior disturbs the error handling operation like
removing pagecache, which results in the malfunction described above.

So convert TTU_IGNORE_HWPOISON into TTU_HWPOISON and set TTU_HWPOISON only
when we really intend to convert pte to hwpoison entry.  This can prevent
other callers of try_to_unmap() from accidentally converting to hwpoison
entries.

Link: https://lkml.kernel.org/r/20230221085905.1465385-1-naoya.horiguchi@linux.dev
Fixes: a42634a6c07d ("readahead: Use a folio in read_pages()")
Signed-off-by: Naoya Horiguchi 
Cc: David Hildenbrand 
Cc: Hugh Dickins 
Cc: Matthew Wilcox 
Cc: Miaohe Lin 
Cc: Minchan Kim 
Cc: Vlastimil Babka 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

mm/memory-failure.c: cleanup in unpoison_memory

2022-11-30T23:59:08+00:00

If freeit is true, the value of ret must be zero, there is no need to
check the value of freeit after label unlock_mutex.

We can drop variable freeit to do this cleanup.

Link: https://lkml.kernel.org/r/20221125065444.3462681-1-mawupeng1@huawei.com
Signed-off-by: Ma Wupeng 
Acked-by: Naoya Horiguchi 
Reviewed-by: Miaohe Lin 
Cc: zhenwei pi 
Signed-off-by: Andrew Morton

memory-failure: convert truncate_error_page() to use folio

2022-11-30T23:59:02+00:00

Replace try_to_release_page() with filemap_release_folio().  This change
is in preparation for the removal of the try_to_release_page() wrapper.

Link: https://lkml.kernel.org/r/20221118073055.55694-4-vishal.moola@gmail.com
Signed-off-by: Vishal Moola (Oracle) 
Acked-by: Naoya Horiguchi 
Cc: Matthew Wilcox 
Cc: Theodore Ts'o 
Signed-off-by: Andrew Morton

mm,hugetlb: use folio fields in second tail page

2022-11-30T23:58:46+00:00

Patch series "mm,huge,rmap: unify and speed up compound mapcounts".


This patch (of 3):

We want to declare one more int in the first tail of a compound page: that
first tail page being valuable property, since every compound page has a
first tail, but perhaps no more than that.

No problem on 64-bit: there is already space for it.  No problem with
32-bit THPs: 5.18 commit 5232c63f46fd ("mm: Make compound_pincount always
available") kindly cleared the space for it, apparently not realizing that
only 64-bit architectures enable CONFIG_THP_SWAP (whose use of tail
page->private might conflict) - but make sure of that in its Kconfig.

But hugetlb pages use tail page->private of the first tail page for a
subpool pointer, which will conflict; and they also use page->private of
the 2nd, 3rd and 4th tails.

Undo "mm: add private field of first tail to struct page and struct
folio"'s recent addition of private_1 to the folio tail: instead add
hugetlb_subpool, hugetlb_cgroup, hugetlb_cgroup_rsvd, hugetlb_hwpoison to
a second tail page of the folio: THP has long been using several fields of
that tail, so make better use of it for hugetlb too.  This is not how a
generic folio should be declared in future, but it is an effective
transitional way to make use of it.

Delete the SUBPAGE_INDEX stuff, but keep __NR_USED_SUBPAGE: now 3.

[hughd@google.com: prefix folio's page_1 and page_2 with double underscore,
  give folio's _flags_2 and _head_2 a line documentation each]
  Link: https://lkml.kernel.org/r/9e2cb6b-5b58-d3f2-b5ee-5f8a14e8f10@google.com
Link: https://lkml.kernel.org/r/5f52de70-975-e94f-f141-543765736181@google.com
Link: https://lkml.kernel.org/r/3818cc9a-9999-d064-d778-9c94c5911e6@google.com
Signed-off-by: Hugh Dickins 
Acked-by: Kirill A. Shutemov 
Cc: David Hildenbrand 
Cc: James Houghton 
Cc: John Hubbard 
Cc: Matthew Wilcox (Oracle) 
Cc: Miaohe Lin 
Cc: Mike Kravetz 
Cc: Mina Almasry 
Cc: Muchun Song 
Cc: Naoya Horiguchi 
Cc: Peter Xu 
Cc: Sidhartha Kumar 
Cc: Vlastimil Babka 
Cc: Yang Shi 
Cc: Zach O'Keefe 
Signed-off-by: Andrew Morton

Merge branch 'mm-hotfixes-stable' into mm-stable

2022-11-30T22:58:42+00:00

mm/hwpoison: introduce per-memory_block hwpoison counter

2022-11-09T01:37:22+00:00

Currently PageHWPoison flag does not behave well when experiencing memory
hotremove/hotplug.  Any data field in struct page is unreliable when the
associated memory is offlined, and the current mechanism can't tell
whether a memory block is onlined because a new memory devices is
installed or because previous failed offline operations are undone. 
Especially if there's a hwpoisoned memory, it's unclear what the best
option is.

So introduce a new mechanism to make struct memory_block remember that a
memory block has hwpoisoned memory inside it.  And make any online event
fail if the onlining memory block contains hwpoison.  struct memory_block
is freed and reallocated over ACPI-based hotremove/hotplug, but not over
sysfs-based hotremove/hotplug.  So the new counter can distinguish these
cases.

Link: https://lkml.kernel.org/r/20221024062012.1520887-5-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi 
Reported-by: kernel test robot 
Reviewed-by: Miaohe Lin 
Cc: David Hildenbrand 
Cc: Jane Chu 
Cc: Mike Kravetz 
Cc: Muchun Song 
Cc: Oscar Salvador 
Cc: Yang Shi 
Signed-off-by: Andrew Morton

mm/hwpoison: pass pfn to num_poisoned_pages_*()

2022-11-09T01:37:22+00:00

No functional change.

Link: https://lkml.kernel.org/r/20221024062012.1520887-4-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi 
Reviewed-by: Miaohe Lin 
Cc: David Hildenbrand 
Cc: Jane Chu 
Cc: Mike Kravetz 
Cc: Muchun Song 
Cc: Oscar Salvador 
Cc: Yang Shi 
Signed-off-by: Andrew Morton

mm/hwpoison: move definitions of num_poisoned_pages_* to memory-failure.c

2022-11-09T01:37:22+00:00

These interfaces will be used by drivers/base/memory.c by later patch, so
as a preparatory work move them to more common header file visible to the
file.

Link: https://lkml.kernel.org/r/20221024062012.1520887-3-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi 
Reviewed-by: Miaohe Lin 
Cc: David Hildenbrand 
Cc: Jane Chu 
Cc: Mike Kravetz 
Cc: Muchun Song 
Cc: Oscar Salvador 
Cc: Yang Shi 
Signed-off-by: Andrew Morton

mm,hwpoison,hugetlb,memory_hotplug: hotremove memory section with hwpoisoned hugepage

2022-11-09T01:37:21+00:00

Patch series "mm, hwpoison: improve handling workload related to hugetlb
and memory_hotplug", v7.

This patchset tries to solve the issue among memory_hotplug, hugetlb and hwpoison.
In this patchset, memory hotplug handles hwpoison pages like below:

  - hwpoison pages should not prevent memory hotremove,
  - memory block with hwpoison pages should not be onlined.


This patch (of 4):

HWPoisoned page is not supposed to be accessed once marked, but currently
such accesses can happen during memory hotremove because
do_migrate_range() can be called before dissolve_free_huge_pages() is
called.

Clear HPageMigratable for hwpoisoned hugepages to prevent them from being
migrated.  This should be done in hugetlb_lock to avoid race against
isolate_hugetlb().

get_hwpoison_huge_page() needs to have a flag to show it's called from
unpoison to take refcount of hwpoisoned hugepages, so add it.

[naoya.horiguchi@linux.dev: remove TestClearHPageMigratable and reduce to test and clear separately]
  Link: https://lkml.kernel.org/r/20221025053559.GA2104800@ik1-406-35019.vs.sakura.ne.jp
Link: https://lkml.kernel.org/r/20221024062012.1520887-1-naoya.horiguchi@linux.dev
Link: https://lkml.kernel.org/r/20221024062012.1520887-2-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi 
Reported-by: Miaohe Lin 
Reviewed-by: Oscar Salvador 
Reviewed-by: Miaohe Lin 
Cc: David Hildenbrand 
Cc: Jane Chu 
Cc: Mike Kravetz 
Cc: Muchun Song 
Cc: Yang Shi 
Signed-off-by: Andrew Morton

mm: memory-failure: make action_result() return int

2022-11-09T01:37:21+00:00

Check mf_result in action_result(), only return 0 when MF_RECOVERED,
or return -EBUSY, which will simplify code a bit.

[wangkefeng.wang@huawei.com: v2]
  Link: https://lkml.kernel.org/r/20221024035138.99119-1-wangkefeng.wang@huawei.com
Link: https://lkml.kernel.org/r/20221021084611.53765-3-wangkefeng.wang@huawei.com
Signed-off-by: Kefeng Wang 
Acked-by: Naoya Horiguchi 
Reviewed-by: Miaohe Lin 
Signed-off-by: Andrew Morton