linux-kernel - Re: [RFC PATCH 01/10] kho: drop restriction on maximum page order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <86ikdp7zh3.fsf@kernel.org>
Date: Mon, 29 Dec 2025 22:24:56 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Pratyush Yadav <pratyush@...nel.org>,  Mike Rapoport <rppt@...nel.org>,
  Andrew Morton <akpm@...ux-foundation.org>,  David Hildenbrand
 <david@...nel.org>,  Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,  "Liam
 R. Howlett" <Liam.Howlett@...cle.com>,  Vlastimil Babka <vbabka@...e.cz>,
  Suren Baghdasaryan <surenb@...gle.com>,  Michal Hocko <mhocko@...e.com>,
  Jonathan Corbet <corbet@....net>,  Thomas Gleixner <tglx@...utronix.de>,
  Ingo Molnar <mingo@...hat.com>,  Borislav Petkov <bp@...en8.de>,  Dave
 Hansen <dave.hansen@...ux.intel.com>,  x86@...nel.org,  "H. Peter Anvin"
 <hpa@...or.com>,  Muchun Song <muchun.song@...ux.dev>,  Oscar Salvador
 <osalvador@...e.de>,  Alexander Graf <graf@...zon.com>,  David Matlack
 <dmatlack@...gle.com>,  David Rientjes <rientjes@...gle.com>,  Jason
 Gunthorpe <jgg@...dia.com>,  Samiullah Khawaja <skhawaja@...gle.com>,
  Vipin Sharma <vipinsh@...gle.com>,  Zhu Yanjun <yanjun.zhu@...ux.dev>,
  linux-kernel@...r.kernel.org,  linux-mm@...ck.org,
  linux-doc@...r.kernel.org,  kexec@...ts.infradead.org
Subject: Re: [RFC PATCH 01/10] kho: drop restriction on maximum page order

On Tue, Dec 23 2025, Pasha Tatashin wrote:

> On Sat, Dec 6, 2025 at 6:03 PM Pratyush Yadav <pratyush@...nel.org> wrote:
>>
>> KHO currently restricts the maximum order of a restored page to the
>> maximum order supported by the buddy allocator. While this works fine
>> for much of the data passed across kexec, it is possible to have pages
>> larger than MAX_PAGE_ORDER.
>>
>> For one, it is possible to get a larger order when using
>> kho_preserve_pages() if the number of pages is large enough, since it
>> tries to combine multiple aligned 0-order preservations into one higher
>> order preservation.
>>
>> For another, upcoming support for hugepages can have gigantic hugepages
>> being preserved over KHO.
>>
>> There is no real reason for this limit. The KHO preservation machinery
>> can handle any page order. Remove this artificial restriction on max
>> page order.
>
> Before removing this restriction, please also add a patch that makes
> sure that the calculated order does not intermix memory from different
> topologies.
>
> I suspect we need something like this in kho_preserve_pages():
>
> order = min(count_trailing_zeros(pfn), ilog2(end_pfn - pfn));
> /* Reduce order if the block spans across NUMA nodes. */
> while (order > 0) {
>    size_pfn = 1UL << order;
>    if (pfn_to_nid(pfn) == pfn_to_nid(pfn + size_pfn - 1))
>      break;
>    order--;
> }

ACK. Will do. And I think I will split it out of the HugeTLB series
since I think this can be applied independently.

-- 
Regards,
Pratyush Yadav