linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Boudewijn van der Heide <boudewijn@delta-utec.com>
To: jiaqiyan@google.com
Cc: akpm@linux-foundation.org, boudewijn@delta-utec.com,
	hannes@cmpxchg.org, jackmanb@google.com, linmiaohe@huawei.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	mhocko@suse.com, nao.horiguchi@gmail.com, osalvador@suse.de,
	surenb@google.com, vbabka@suse.cz, ziy@nvidia.com
Subject: Re: [PATCH] mm/page_alloc: Fix freeing of failed-split poisoned compound pages
Date: Fri, 16 Jan 2026 15:11:57 +0100	[thread overview]
Message-ID: <20260116141157.29578-1-boudewijn@delta-utec.com> (raw)
In-Reply-To: <CACw3F52D8=s_uj_jRtw1J-GjAvt4c3HNMKb2sJGUjznvyAK80A@mail.gmail.com>

Thanks Jiaqi for the feedback, that is very helpful.
(and thanks Miaohe for connecting the issues.)

After going through the memory_failure(),
I can see it indeed puts the PG_HWPoison flag on the specific subpage pointer,
and therefore my fix won't work as-is.

> >
> > Yes, this is also a problematic scenario for Hugetlb HugePage. And Jiaqi works on
> > it now [1]. I think Jiaqi's patches might apply to THP scenario too. Add @Jiaqi to
> > verify this.
> 
> Yep, I think my work will also help solve the concern when
> try_to_split_thp_page() fails.

Your fix makes a lot of sense for hugetlb,
as it linearly scans through all the pages.
From my understanding, 
your fix also provides the perfect architecture for also checking THP,
though it doesn't yet cover the in-use THP case outlined.

For THP I would need to trace the failed-split paths more carefully,
to check where the equivalent path for THP would be. 

If there is work needed for THP, I'm happy to help.
Would you prefer I work on THP support as a separate follow-up patch,
after yours is merged,
or do you prefer to integrate it in your patch series?

> >
> > [1]: https://lore.kernel.org/all/20260112004923.888429-1-jiaqiyan@google.com/
> >
> > Thanks.
> > .

Thanks,
Boudewijn


  reply	other threads:[~2026-01-16 14:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-13 20:54 Boudewijn van der Heide
2026-01-13 21:05 ` Zi Yan
2026-01-14 14:48   ` Boudewijn van der Heide
2026-01-15  7:55     ` Miaohe Lin
2026-01-15 17:11       ` Jiaqi Yan
2026-01-16 14:11         ` Boudewijn van der Heide [this message]
2026-01-24  4:42           ` Jiaqi Yan
2026-01-28  2:45             ` 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=20260116141157.29578-1-boudewijn@delta-utec.com \
    --to=boudewijn@delta-utec.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=jackmanb@google.com \
    --cc=jiaqiyan@google.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=nao.horiguchi@gmail.com \
    --cc=osalvador@suse.de \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=ziy@nvidia.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