linux-kernel - Re: [PATCH] mm/hugetlb: Remove prepare_hugepage

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: <g4odcoaq4sf3iubkole75bvq5ezfg7bjvd7ritfwbekzl4sxi5@p4q7i3jfvapw>
Date: Wed, 2 Jul 2025 13:39:33 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Peter Xu <peterx@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Huacai Chen <chenhuacai@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Muchun Song <muchun.song@...ux.dev>,
        Oscar Salvador <osalvador@...e.de>, loongarch@...ts.linux.dev,
        linux-mips@...r.kernel.org, Jason Gunthorpe <jgg@...dia.com>,
        David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH] mm/hugetlb: Remove prepare_hugepage_range()

* Peter Xu <peterx@...hat.com> [250702 13:20]:
> On Mon, Jun 30, 2025 at 10:26:13AM -0400, Liam R. Howlett wrote:
> > * Peter Xu <peterx@...hat.com> [250627 12:07]:
> > > Only mips and loongarch implemented this API, however what it does was
> > > checking against stack overflow for either len or addr.  That's already
> > > done in arch's arch_get_unmapped_area*() functions, even though it may not
> > > be 100% identical checks.
> > > 
> > > For example, for both of the architectures, there will be a trivial
> > > difference on how stack top was defined.  The old code uses STACK_TOP which
> > > may be slightly smaller than TASK_SIZE on either of them, but the hope is
> > > that shouldn't be a problem.
> > > 
> > > It means the whole API is pretty much obsolete at least now, remove it
> > > completely.
> > 
> > Thanks for rewording this change, apologies for the late response on
> > your change log.  I think it's fine.
> 
> That's totally OK, thanks for keeping an eye.
> 
> > 
> > I think the only meaningful difference is that the failure would have
> > aborted entirely if stack_top - len < addr, but with this change it will
> > attempt to search in the opposite direction.  Unless I missed something?
> 
> IIUC the prepare_hugepage_range() API shouldn't affect the direction of VA
> allocation yet, but rather a (likely proven unnecessary by this patch) way
> to fail fast for hugetlbfs for no good reason.
> 
> It is currently only invoked with MAP_FIXED, and if it returns 0 it'll
> further move on to the core VA allocator.  Then the allocation can happen
> either TOP->DOWN or DOWN->TOP.
> 
> So "stack_top - len < addr" check is meaningful no matter if MMF_TOPDOWN or
> not, because we want to make sure it won't overflow in any direction.  It's
> just that it's already covered at least by the two archs providing this
> hugetlbfs specific hook.

What I meant was, before your change the failure would happen before the
we get to the core VA allocator, so the reverse direction would never
happen.

If this is only used with MAP_FIXED, then I don't think it matters as
many tests are skipped anyways.  It might be worth mentioning that the
MAP_FIXED flag is checked in different orders based on the arch, again I
think this change resulted from forked archs cloning the code and
keeping up to date.

Thanks,
Liam