[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b65297e0-0ea7-4ac4-88be-fa89d6749d7a@kernel.org>
Date: Thu, 25 Dec 2025 10:32:46 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Matthew Wilcox <willy@...radead.org>,
David Laight <david.laight.linux@...il.com>
Cc: Lance Yang <ioworker0@...il.com>, baolin.wang@...ux.alibaba.com,
Liam.Howlett@...cle.com, akpm@...ux-foundation.org,
axelrasmussen@...gle.com, chandna.sahil@...il.com, chengming.zhou@...ux.dev,
hannes@...xchg.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
lorenzo.stoakes@...cle.com, mhocko@...e.com, nphamcs@...il.com,
rppt@...nel.org, shakeel.butt@...ux.dev, surenb@...gle.com, vbabka@...e.cz,
weixugc@...gle.com, yosry.ahmed@...ux.dev, yuanchu@...gle.com,
zhengqi.arch@...edance.com, Lance Yang <lance.yang@...ux.dev>
Subject: Re: [PATCH v4 1/3] mm: pagewalk: simplify hugepage boundary
On 12/24/25 19:06, Matthew Wilcox wrote:
> On Wed, Dec 24, 2025 at 02:08:29PM +0000, David Laight wrote:
>>>>> +++ b/mm/pagewalk.c
>>>>> @@ -312,8 +312,7 @@ static int walk_pgd_range(unsigned long addr, unsigned long end,
>>>>> static unsigned long hugetlb_entry_end(struct hstate *h, unsigned long addr,
>>>>> unsigned long end)
>>>>> {
>>>>> - unsigned long boundary = (addr & huge_page_mask(h)) + huge_page_size(h);
>>>>> - return boundary < end ? boundary : end;
>>>>> + return min(ALIGN(addr, huge_page_size(h)), end);
>>>>> }
>>>>
>>>> Please drop this patch from the mm-new branch, as it causes
>>>> 'run_vmtests.sh' to hang. Specifically, it leads to the system hanging
>>>> when executing hugepage-vmemmap test, because the program falls into an
>>>> infinite loop in walk_hugetlb_range() and cannot break out.
>>>
>>> Good catch! The problem is that ALIGN() returns addr itself when already
>>> aligned, causing the infinite loop ...
>>
>> Using ALIGN(addr + 1, huge_page_size(h)) would work.
>> Although it could be (addr + 1) & ~huge_page_mask(h) which is probably
>> the easiest to understand.
>> Some of the 'helper' macros don't really make the code easier to read.
>> (And that includes a lot of uses of min().)
>
> Or we could go back to my original suggestion.
>
> https://lore.kernel.org/linux-mm/aRyOWrARRlUCeEz6@casper.infradead.org/
>
> which was in v2:
>
> https://lore.kernel.org/linux-mm/f802959f58865371ba1b10081bced98e3784c5e4.1763796152.git.chandna.sahil@gmail.com/
I'm starting to wonder whether we should just leave that code alone :)
--
Cheers
David
Powered by blists - more mailing lists