From: Wei Yang <richardw.yang@linux.intel.com>
To: David Hildenbrand <david@redhat.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>,
n-horiguchi@ah.jp.nec.com, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
James Morse <james.morse@arm.com>
Subject: Re: [PATCH 1/2] mm/memory-failure.c: PageHuge is handled at the beginning of memory_failure
Date: Thu, 21 Nov 2019 09:07:39 +0800 [thread overview]
Message-ID: <20191121010739.GB12975@richard> (raw)
In-Reply-To: <a85053b7-9298-9dd3-3826-e63cf8c7bd81@redhat.com>
On Wed, Nov 20, 2019 at 04:04:44PM +0100, David Hildenbrand wrote:
>On 20.11.19 01:46, Wei Yang wrote:
>> On Tue, Nov 19, 2019 at 01:23:54PM +0100, David Hildenbrand wrote:
>> > On 18.11.19 09:20, Wei Yang wrote:
>> > > PageHuge is handled by memory_failure_hugetlb(), so this case could be
>> > > removed.
>> > >
>> > > Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
>> > > ---
>> > > mm/memory-failure.c | 5 +----
>> > > 1 file changed, 1 insertion(+), 4 deletions(-)
>> > >
>> > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> > > index 3151c87dff73..392ac277b17d 100644
>> > > --- a/mm/memory-failure.c
>> > > +++ b/mm/memory-failure.c
>> > > @@ -1359,10 +1359,7 @@ int memory_failure(unsigned long pfn, int flags)
>> > > * page_remove_rmap() in try_to_unmap_one(). So to determine page status
>> > > * correctly, we save a copy of the page flags at this time.
>> > > */
>> > > - if (PageHuge(p))
>> > > - page_flags = hpage->flags;
>> > > - else
>> > > - page_flags = p->flags;
>> > > + page_flags = p->flags;
>> > > /*
>> > > * unpoison always clear PG_hwpoison inside page lock
>> > >
>> >
>> > I somewhat miss a proper explanation why this is safe to do. We access page
>> > flags here, so why is it safe to refer to the ones of the sub-page?
>> >
>>
>> Hi, David
>>
>> I think your comment is on this line:
>>
>> page_flags = p->flags;
>>
>> Maybe we need to use this:
>>
>> page_flags = hpage->flags;
>>
>> And use hpage in the following or even the whole function?
>>
>> While one thing interesting is not all "compound page" is PageCompound. For
>> some sub-page, we can't get the correct head. This means we may just check on
>> the sub-page.
>
>Oh wait, I think I missed the check right at the beginning of this function,
>sorry :/
>
>Sooo, memory_failure_hugetlb() was introduced by
>
>commit 761ad8d7c7b5485bb66fd5bccb58a891fe784544
>Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>Date: Mon Jul 10 15:47:47 2017 -0700
>
> mm: hwpoison: introduce memory_failure_hugetlb()
>
>and essentially ripped out all PageHuge() checks *except* this check. This
>check was introduced in
>
>commit 7258ae5c5a2ce2f5969e8b18b881be40ab55433d
>Author: James Morse <james.morse@arm.com>
>Date: Fri Jun 16 14:02:29 2017 -0700
>
> mm/memory-failure.c: use compound_head() flags for huge pages
>
>
>Maybe that was just a merge oddity as both commits are only ~1month apart.
>IOW, I think Naoya's patch forgot to rip it out.
>
>
>Can we make this clear in the patch description like "This is dead code that
>cannot be reached after commit 761ad8d7c7b5 ("mm: hwpoison: introduce
>memory_failure_hugetlb()")"
>
>I assume Andrew can fix up when applying
>
That's very helpful. Thanks for your time sincerely.
>Reviewed-by: David Hildenbrand <david@redhat.com>
>
>--
>
>Thanks,
>
>David / dhildenb
--
Wei Yang
Help you, Help me
prev parent reply other threads:[~2019-11-21 1:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-18 8:20 [PATCH 1/2] mm/memory-failure.c: PageHuge is handled at the beginning of memory_failure Wei Yang
2019-11-18 8:20 ` [PATCH 2/2] mm/memory-failure.c: not necessary to recalculate hpage Wei Yang
2019-11-20 15:07 ` David Hildenbrand
2019-11-21 1:05 ` Wei Yang
2019-12-02 22:28 ` Wei Yang
2019-12-05 15:06 ` David Hildenbrand
2019-12-06 1:48 ` Wei Yang
2020-01-08 12:20 ` David Hildenbrand
2020-01-09 1:58 ` Wei Yang
2019-11-19 12:23 ` [PATCH 1/2] mm/memory-failure.c: PageHuge is handled at the beginning of memory_failure David Hildenbrand
2019-11-20 0:46 ` Wei Yang
2019-11-20 15:04 ` David Hildenbrand
2019-11-21 1:07 ` Wei Yang [this message]
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=20191121010739.GB12975@richard \
--to=richardw.yang@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.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.