Re: [PATCH v1 6/6] mm/hwpoison: fix unpoison_memory()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021/6/14 10:12, Naoya Horiguchi wrote:
From: Naoya Horiguchi <naoya.horiguchi@xxxxxxx>

After recent soft-offline rework, error pages can be taken off from
buddy allocator, but the existing unpoison_memory() does not properly
undo the operation.  Moreover, due to the recent change on
__get_hwpoison_page(), get_page_unless_zero() is hardly called for
hwpoisoned pages.  So __get_hwpoison_page() mostly returns zero (meaning
to fail to grab page refcount) and unpoison just clears PG_hwpoison
without releasing a refcount.  That does not lead to a critical issue
like kernel panic, but unpoisoned pages never get back to buddy (leaked
permanently), which is not good.

As I mention in [1], I'm not sure about the exactly meaning of "broken" in unpoison_memory().

Maybe the misunderstanding is:

I think __get_hwpoison_page() mostly returns one for hwpoisoned page.
In 06be6ff3d2ec ("mm,hwpoison: rework soft offline for free pages"), page_handle_poison() is introduced, it will add refcount for all soft-offlineed hwpoison page. In memory_failure() for hard-offline,page_ref_inc() called on free page too, and for used page, we do not call put_page() after get_hwpoison_page() != 0. So all hwpoisoned page refcount must be great than zero when unpoison_memory() if regardless of racy.

Recently I tested loop soft-offline random pages and unpoison them for days, it works fine to me. (with bac9c6fa1f92 patched)

[1]: https://lore.kernel.org/lkml/6af291a0-41fa-8112-5297-6a4cdf2337b6@xxxxxxxxxxxxxx/


To fix this, we need to identify "taken off" pages from other types of
hwpoisoned pages.  We can't use refcount or page flags for this purpose,
so a pseudo flag is defined by hacking ->private field.

Sometimes hwpoisoned pages can be still in-use, where the refcount should
be more than 1, so we can't unpoison them immediately and need to wait
until the all users release their refcount.

Signed-off-by: Naoya Horiguchi <naoya.horiguchi@xxxxxxx>
---


--
Thanks,
- Ding Hui





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux