linux.git/mm/memory-failure.c, branch v6.2-rc2

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

mm: memory-failure: avoid pfn_valid() twice in soft_offline_page()

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

Simplify WARN_ON_ONCE(flags & MF_COUNT_INCREASED) under !pfn_valid().

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