[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <h7pqst5vvkahposrvf2iy5qz53t4crrujold2ky4ssrpawaefv@yaqaj3so2hxi>
Date: Tue, 2 Sep 2025 14:21:28 +0100
From: Kiryl Shutsemau <kirill@...temov.name>
To: Pankaj Raghav <kernel@...kajraghav.com>
Cc: David Hildenbrand <david@...hat.com>,
Ryan Roberts <ryan.roberts@....com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>, Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, Nico Pache <npache@...hat.com>, Zi Yan <ziy@...dia.com>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
willy@...radead.org, mcgrof@...nel.org, gost.dev@...sung.com,
Pankaj Raghav <p.raghav@...sung.com>
Subject: Re: [PATCH] huge_memory: return -EINVAL in folio split functions
when THP is disabled
On Tue, Sep 02, 2025 at 03:02:23PM +0200, Pankaj Raghav wrote:
> >> I was hitting a weird stale content read error and finally ended up with this fix.
> >>
> >> I thought this is a self-contained patch that can already be upstream. My argument is not that this
> >> should not be reachable, but returning -EINVAL will do the right thing instead of returning 0, which
> >> means success.
> >
> > Okay, makes sense.
> >
> > In THP=y case, __folio_split() also returns -EINVAL for !large folios,
> > but it is not very explicit:
> >
> > if (new_order >= folio_order(folio))
> > return -EINVAL;
> >
> > In THP=y, we also issue warning:
> >
> > VM_WARN_ON_ONCE_FOLIO(!folio_test_locked(folio), folio);
> >
> You mean:
>
> VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
Yeah, copied wrong line.
> > Makes sense to do the same here for THP=n. It might help to catch cases
> > we do not see with THP=y, like getting non-THP large folios here.
> >
>
> Yeah, I think that is a good idea. Something like this:
>
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 48c4f91c5b13..4ddf9e87db91 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -588,21 +588,29 @@ static inline int
> split_huge_page_to_list_to_order(struct page *page, struct list_head *list,
> unsigned int new_order)
> {
> + struct folio *folio = page_folio(page);
> +
> + VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
No. Make it unconditional. The point is we don't expect to see any
splitable folios, so no reason to get here at all.
You can try to use BUILD_BUG(), but it can be too messy.
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists