From: Ding Hui <dinghui@sangfor.com.cn>
To: Naoya Horiguchi <nao.horiguchi@gmail.com>, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Oscar Salvador <osalvador@suse.de>,
Michal Hocko <mhocko@suse.com>, Tony Luck <tony.luck@intel.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Naoya Horiguchi <naoya.horiguchi@nec.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 6/6] mm/hwpoison: fix unpoison_memory()
Date: Thu, 17 Jun 2021 18:00:21 +0800 [thread overview]
Message-ID: <94984984-f123-85ae-20bc-b40e90d536f6@sangfor.com.cn> (raw)
In-Reply-To: <20210614021212.223326-7-nao.horiguchi@gmail.com>
On 2021/6/14 10:12, Naoya Horiguchi wrote:
> From: Naoya Horiguchi <naoya.horiguchi@nec.com>
>
> 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@sangfor.com.cn/
>
> 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@nec.com>
> ---
--
Thanks,
- Ding Hui
next prev parent reply other threads:[~2021-06-17 10:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 2:12 [PATCH v1 0/6] mm/hwpoison: fix unpoison_memory() Naoya Horiguchi
2021-06-14 2:12 ` [PATCH v1 1/6] mm/hwpoison: mf_mutex for soft offline and unpoison Naoya Horiguchi
2021-06-15 11:41 ` Ding Hui
2021-06-14 2:12 ` [PATCH v1 2/6] mm/hwpoison: remove race consideration Naoya Horiguchi
2021-06-15 12:57 ` Ding Hui
[not found] ` <20210616001141.GA1924716@hori.linux.bs1.fc.nec.co.jp>
2021-06-16 0:40 ` Ding Hui
2021-06-14 2:12 ` [PATCH v1 3/6] mm/hwpoison: introduce MF_MSG_PAGETABLE Naoya Horiguchi
2021-06-14 3:06 ` Matthew Wilcox
2021-06-14 2:12 ` [PATCH v1 4/6] mm/hwpoison: remove MF_MSG_BUDDY_2ND and MF_MSG_POISONED_HUGE Naoya Horiguchi
2021-06-14 2:12 ` [PATCH v1 5/6] mm/hwpoison: make some kernel pages handlable Naoya Horiguchi
2021-07-28 10:59 ` Ding Hui
2021-06-14 2:12 ` [PATCH v1 6/6] mm/hwpoison: fix unpoison_memory() Naoya Horiguchi
2021-06-17 10:00 ` Ding Hui [this message]
[not found] ` <20210618083625.GA2215283@hori.linux.bs1.fc.nec.co.jp>
2021-06-19 12:22 ` Ding Hui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94984984-f123-85ae-20bc-b40e90d536f6@sangfor.com.cn \
--to=dinghui@sangfor.com.cn \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=nao.horiguchi@gmail.com \
--cc=naoya.horiguchi@nec.com \
--cc=osalvador@suse.de \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).