linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>
To: Miaohe Lin <linmiaohe@huawei.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 5/6] mm, hwpoison: kill procs if unmap fails
Date: Fri, 19 Aug 2022 05:24:31 +0000	[thread overview]
Message-ID: <20220819052431.GE613144@hori.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <20220818130016.45313-6-linmiaohe@huawei.com>

On Thu, Aug 18, 2022 at 09:00:15PM +0800, Miaohe Lin wrote:
> If try_to_unmap() fails, the hwpoisoned page still resides in the address
> space of some processes. We should kill these processes or the hwpoisoned
> page might be consumed later. collect_procs() is always called to collect
> relevant processes now so they can be killed later if unmap fails.
> 
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> ---
>  mm/memory-failure.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index a2f4e8b00a26..5f9615a86296 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1396,7 +1396,7 @@ static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
>  	struct address_space *mapping;
>  	LIST_HEAD(tokill);
>  	bool unmap_success;
> -	int kill = 1, forcekill;
> +	int forcekill;
>  	bool mlocked = PageMlocked(hpage);
>  
>  	/*
> @@ -1437,7 +1437,6 @@ static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
>  		if (page_mkclean(hpage)) {
>  			SetPageDirty(hpage);
>  		} else {
> -			kill = 0;
>  			ttu |= TTU_IGNORE_HWPOISON;
>  			pr_info("%#lx: corrupted page was clean: dropped without side effects\n",
>  				pfn);
> @@ -1452,8 +1451,7 @@ static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
>  	 * Error handling: We ignore errors here because
>  	 * there's nothing that can be done.

This above comment might be deprecated now (I'm not sure what this really mean),
so could you drop or update this?

Anyway, the patch looks good to me.

Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>

>  	 */
> -	if (kill)
> -		collect_procs(hpage, &tokill, flags & MF_ACTION_REQUIRED);
> +	collect_procs(hpage, &tokill, flags & MF_ACTION_REQUIRED);
>  
>  	if (PageHuge(hpage) && !PageAnon(hpage)) {
>  		/*
> @@ -1495,7 +1493,8 @@ static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
>  	 * use a more force-full uncatchable kill to prevent
>  	 * any accesses to the poisoned memory.
>  	 */
> -	forcekill = PageDirty(hpage) || (flags & MF_MUST_KILL);
> +	forcekill = PageDirty(hpage) || (flags & MF_MUST_KILL) ||
> +		    !unmap_success;
>  	kill_procs(&tokill, forcekill, !unmap_success, pfn, flags);
>  
>  	return unmap_success;
> -- 
> 2.23.0

  reply	other threads:[~2022-08-19  5:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-18 13:00 [PATCH 0/6] A few fixup patches for hugetlb Miaohe Lin
2022-08-18 13:00 ` [PATCH 1/6] mm, hwpoison: fix page refcnt leaking in try_memory_failure_hugetlb() Miaohe Lin
2022-08-19  5:20   ` HORIGUCHI NAOYA(堀口 直也)
2022-08-18 13:00 ` [PATCH 2/6] mm, hwpoison: fix page refcnt leaking in unpoison_memory() Miaohe Lin
2022-08-19  5:21   ` HORIGUCHI NAOYA(堀口 直也)
2022-08-18 13:00 ` [PATCH 3/6] mm, hwpoison: fix extra put_page() in soft_offline_page() Miaohe Lin
2022-08-19  5:21   ` HORIGUCHI NAOYA(堀口 直也)
2022-08-18 13:00 ` [PATCH 4/6] mm, hwpoison: fix possible use-after-free in mf_dax_kill_procs() Miaohe Lin
2022-08-19  5:23   ` HORIGUCHI NAOYA(堀口 直也)
2022-08-19  7:32     ` Miaohe Lin
2022-08-18 13:00 ` [PATCH 5/6] mm, hwpoison: kill procs if unmap fails Miaohe Lin
2022-08-19  5:24   ` HORIGUCHI NAOYA(堀口 直也) [this message]
2022-08-19  7:37     ` Miaohe Lin
2022-08-19  8:18       ` HORIGUCHI NAOYA(堀口 直也)
2022-08-18 13:00 ` [PATCH 6/6] mm, hwpoison: avoid trying to unpoison reserved page Miaohe Lin
2022-08-19  5:24   ` HORIGUCHI NAOYA(堀口 直也)
2022-08-18 13:05 ` [PATCH 0/6] A few fixup patches for hugetlb Miaohe Lin

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=20220819052431.GE613144@hori.linux.bs1.fc.nec.co.jp \
    --to=naoya.horiguchi@nec.com \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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