All of lore.kernel.org
 help / color / mirror / Atom feed
From: Naoya Horiguchi <naoya.horiguchi@linux.dev>
To: Miaohe Lin <linmiaohe@huawei.com>
Cc: akpm@linux-foundation.org, naoya.horiguchi@nec.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/8] mm/memory-failure.c: remove unneeded orig_head
Date: Mon, 14 Feb 2022 23:50:19 +0900	[thread overview]
Message-ID: <20220214145019.GD2624914@u2004> (raw)
In-Reply-To: <20220210141733.1908-5-linmiaohe@huawei.com>

On Thu, Feb 10, 2022 at 10:17:29PM +0800, Miaohe Lin wrote:
> orig_head is used to check whether the page have changed compound pages
> during the locking. But it's always equal to hpage. So we can use hpage
> directly and remove this redundant one.
> 
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> ---
>  mm/memory-failure.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 2dd7f35ee65a..4370c2f407c5 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1691,7 +1691,6 @@ int memory_failure(unsigned long pfn, int flags)
>  {
>  	struct page *p;
>  	struct page *hpage;
> -	struct page *orig_head;
>  	struct dev_pagemap *pgmap;
>  	int res = 0;
>  	unsigned long page_flags;
> @@ -1737,7 +1736,7 @@ int memory_failure(unsigned long pfn, int flags)
>  		goto unlock_mutex;
>  	}
> 
> -	orig_head = hpage = compound_head(p);
> +	hpage = compound_head(p);
>  	num_poisoned_pages_inc();
> 
>  	/*
> @@ -1821,7 +1820,7 @@ int memory_failure(unsigned long pfn, int flags)
>  	 * The page could have changed compound pages during the locking.
>  	 * If this happens just bail out.
>  	 */
> -	if (PageCompound(p) && compound_head(p) != orig_head) {
> +	if (PageCompound(p) && compound_head(p) != hpage) {

I think that this if-check was intended to detect the case that page p
belongs to a thp when memory_failure() is called and belongs to a compound
page in different size (like slab or some driver page) after the thp is
split.  But your suggestion makes me aware that the page p could be embedded
on a thp again after thp split.  I think this might be rare, but if it
happens the current if-check (or suggested one) cannot detect it.
So I feel that simply dropping compound_head() check might be better?

-	if (PageCompound(p) && compound_head(p) != orig_head) {
+	if (PageCompound(p)) {

This should ensure the assumption (mentioned in 8/8 patch) more that
the error page never belongs to compound page after taking page lock.

Thanks,
Naoya Horiguchi


  reply	other threads:[~2022-02-14 14:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 14:17 [PATCH 0/8] mm/memory-failure.c: A few cleanup patches for memory failure Miaohe Lin
2022-02-10 14:17 ` [PATCH 1/8] mm/memory-failure.c: minor clean up for memory_failure_dev_pagemap Miaohe Lin
2022-02-14 14:47   ` Naoya Horiguchi
2022-02-10 14:17 ` [PATCH 2/8] mm/memory-failure.c: avoid walking page table when vma_address() return -EFAULT Miaohe Lin
2022-02-14 14:48   ` Naoya Horiguchi
2022-02-15  2:40     ` Miaohe Lin
2022-02-15  8:37       ` HORIGUCHI NAOYA(堀口 直也)
2022-02-15  9:35         ` Miaohe Lin
2022-02-10 14:17 ` [PATCH 3/8] mm/memory-failure.c: rework the signaling logic in kill_proc Miaohe Lin
2022-02-14 14:48   ` Naoya Horiguchi
2022-02-10 14:17 ` [PATCH 4/8] mm/memory-failure.c: remove unneeded orig_head Miaohe Lin
2022-02-14 14:50   ` Naoya Horiguchi [this message]
2022-02-15  3:14     ` Miaohe Lin
2022-02-15  8:48       ` HORIGUCHI NAOYA(堀口 直也)
2022-02-15  9:28         ` Miaohe Lin
2022-02-10 14:17 ` [PATCH 5/8] mm/memory-failure.c: remove PageSlab check in hwpoison_filter_dev Miaohe Lin
2022-02-14 14:50   ` Naoya Horiguchi
2022-02-10 14:17 ` [PATCH 6/8] mm/memory-failure.c: rework the try_to_unmap logic in hwpoison_user_mappings() Miaohe Lin
2022-02-14 14:51   ` Naoya Horiguchi
2022-02-10 14:17 ` [PATCH 7/8] mm/memory-failure.c: remove obsolete comment in __soft_offline_page Miaohe Lin
2022-02-10 14:17 ` [PATCH 8/8] mm/memory-failure.c: remove unnecessary PageTransTail check Miaohe Lin
2022-02-14 14:54   ` 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=20220214145019.GD2624914@u2004 \
    --to=naoya.horiguchi@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.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.