From: "HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>
To: luofei <luofei@unicloud.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/hwpoison: In-use hugepage need filter judgement and filter return value should be consistent
Date: Wed, 16 Feb 2022 01:44:13 +0000 [thread overview]
Message-ID: <20220216014413.GA2233606@hori.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <20220210085846.902394-1-luofei@unicloud.com>
On Thu, Feb 10, 2022 at 03:58:46AM -0500, luofei wrote:
> After successfully obtaining the reference count of the huge
> page, it is still necessary to call hwpoison_filter() to make a
> filter judgement, otherwise the filter page will be unmaped and
> the related process may be killed.
>
> Also when the huge page meets the filter conditions, it should
> not be regarded as successful memory_failure() processing, but
> should return an error code to inform the caller, otherwise the
> caller regards the error page has been identified and isolated,
> which may lead to calling set_mce_nospec() to change page attribute.
Hi luofei,
I agree with inserting another hwpoison_filter() block which was
simply missed. Thanks for pointing it out.
>
> Meanwhile, when calling hwpoison_filter() to determine that a page
> needs to be filtered, it is better to keep the same EBUSY return
> value, so that the caller can recognize that memory_failure() did
> not successfully process the error page.
IIRC, hwpoison_filter() is expected to ignore error events on
irrelevant target (page|device|cgroup) for testers to focus on
non-filtered events. So filtered events should not be considered
as error-handling failures (otherwise testers can't easily
distinguish them from real error-handling failures).
But yes, the MCE handler depends on the return value of memory_failure(),
so filtered events shouldn't be considered as error-handling's successes.
So one possible approach is that we introduce a new mf_flags to show that
memory_failure() is called from MCE handler (not from hwpoison injector),
and we switch return code when hwpoison_filter failed by this flag.
Could you try it if this approach works for you? Or if you have any better
idea, feel free to share it.
Thanks,
Naoya Horiguchi
>
> Signed-off-by: luofei <luofei@unicloud.com>
> ---
> mm/hwpoison-inject.c | 2 +-
> mm/memory-failure.c | 12 ++++++++++--
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/mm/hwpoison-inject.c b/mm/hwpoison-inject.c
> index aff4d27ec235..4ecd77cd1ded 100644
> --- a/mm/hwpoison-inject.c
> +++ b/mm/hwpoison-inject.c
> @@ -44,7 +44,7 @@ static int hwpoison_inject(void *data, u64 val)
> */
> err = hwpoison_filter(hpage);
> if (err)
> - return 0;
> + return -EBUSY;
>
> inject:
> pr_info("Injecting memory failure at pfn %#lx\n", pfn);
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 97a9ed8f87a9..acf97fb2659a 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1526,7 +1526,7 @@ static int memory_failure_hugetlb(unsigned long pfn, int flags)
> if (TestClearPageHWPoison(head))
> num_poisoned_pages_dec();
> unlock_page(head);
> - return 0;
> + return -EBUSY;
> }
> unlock_page(head);
> res = MF_FAILED;
> @@ -1545,6 +1545,13 @@ static int memory_failure_hugetlb(unsigned long pfn, int flags)
> lock_page(head);
> page_flags = head->flags;
>
> + if (hwpoison_filter(p)) {
> + if (TestClearPageHWPoison(head))
> + num_poisoned_pages_dec();
> + unlock_page(head);
> + res = -EBUSY
> + goto out;
> + }
> /*
> * TODO: hwpoison for pud-sized hugetlb doesn't work right now, so
> * simply disable it. In order to make it work properly, we need
> @@ -1613,7 +1620,7 @@ static int memory_failure_dev_pagemap(unsigned long pfn, int flags,
> goto out;
>
> if (hwpoison_filter(page)) {
> - rc = 0;
> + rc = -EBUSY;
> goto unlock;
> }
>
> @@ -1837,6 +1844,7 @@ int memory_failure(unsigned long pfn, int flags)
> num_poisoned_pages_dec();
> unlock_page(p);
> put_page(p);
> + res = -EBUSY;
> goto unlock_mutex;
> }
>
> --
> 2.27.0
next prev parent reply other threads:[~2022-02-16 1:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-10 8:58 [PATCH] mm/hwpoison: In-use hugepage need filter judgement and filter return value should be consistent luofei
2022-02-16 1:44 ` HORIGUCHI NAOYA(堀口 直也) [this message]
2022-02-16 8:48 ` 答复: " 罗飞
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=20220216014413.GA2233606@hori.linux.bs1.fc.nec.co.jp \
--to=naoya.horiguchi@nec.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luofei@unicloud.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).