All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: Naoya Horiguchi <naoya.horiguchi@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Yang Shi <shy828301@gmail.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	<linux-kernel@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH v8 2/3] mm/hwpoison: put page in already hwpoisoned case with MF_COUNT_INCREASED
Date: Sat, 9 Apr 2022 10:04:41 +0800	[thread overview]
Message-ID: <84062e94-8356-a2b2-1074-e0143297223e@huawei.com> (raw)
In-Reply-To: <20220408135323.1559401-3-naoya.horiguchi@linux.dev>

On 2022/4/8 21:53, Naoya Horiguchi wrote:
> From: Naoya Horiguchi <naoya.horiguchi@nec.com>
> 
> In already hwpoisoned case, memory_failure() is supposed to return with
> releasing the page refcount taken for error handling. But currently the
> refcount is not released when called with MF_COUNT_INCREASED, which
> makes page refcount inconsistent.  This should be rare and non-critical,
> but it might be inconvenient in testing (unpoison doesn't work).

IMHO, this issue will lead to memoryleak as page isn't freed even owner process
is killed. So we might need a Fixes tag?

Anyway, this patch looks good to me. Thanks!
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>

> 
> Suggested-by: Miaohe Lin <linmiaohe@huawei.com>
> Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
> ---
>  mm/memory-failure.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 2020944398c9..b2e32cdc3823 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1811,6 +1811,8 @@ int memory_failure(unsigned long pfn, int flags)
>  		res = -EHWPOISON;
>  		if (flags & MF_ACTION_REQUIRED)
>  			res = kill_accessing_process(current, pfn, flags);
> +		if (flags & MF_COUNT_INCREASED)
> +			put_page(p);
>  		goto unlock_mutex;
>  	}
>  
> 


  reply	other threads:[~2022-04-09  2:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08 13:53 [PATCH v8 0/3] mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb() Naoya Horiguchi
2022-04-08 13:53 ` [PATCH v8 1/3] " Naoya Horiguchi
2022-04-09  2:33   ` Miaohe Lin
2022-04-14 17:56   ` Mike Kravetz
2022-04-15  1:55     ` Miaohe Lin
2022-04-15  2:12       ` HORIGUCHI NAOYA(堀口 直也)
2022-04-15  4:18         ` [PATCH 4/3] mm, hugetlb, hwpoison: separate branch for free and in-use hugepage Naoya Horiguchi
2022-04-15 15:11           ` Mike Kravetz
2022-04-16  1:06           ` Miaohe Lin
2022-04-08 13:53 ` [PATCH v8 2/3] mm/hwpoison: put page in already hwpoisoned case with MF_COUNT_INCREASED Naoya Horiguchi
2022-04-09  2:04   ` Miaohe Lin [this message]
2022-04-14 19:41   ` Mike Kravetz
2022-04-08 13:53 ` [PATCH v8 3/3] Revert "mm/memory-failure.c: fix race with changing page compound again" Naoya Horiguchi
2022-04-09  2:07   ` Miaohe Lin
2022-04-14 17:59   ` Mike Kravetz
2022-04-08 23:47 ` [PATCH v8 0/3] mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb() Andrew Morton
2022-04-09  2:31   ` Naoya Horiguchi

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=84062e94-8356-a2b2-1074-e0143297223e@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=naoya.horiguchi@linux.dev \
    --cc=naoya.horiguchi@nec.com \
    --cc=shy828301@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.