Re: [RFC PATCH 0/9] arm64: Allocate .text and .init.text together

On 8/22/26 3:53 PM, Ard Biesheuvel wrote:

From: Ard Biesheuvel <ardb@kernel.org>

The arm64 module loader has to deal with a couple of corner cases that
may occur when .init.text is placed out of direct branch range of .text:

- ordinary direct branches from .init.text into .text may require the
  use of a PLT entry (i.e., a trampoline aka veneer), which means not
  only that additional PLT entries need to be allocated for
  cross-section calls, but also that .init.text needs its own PLT
  reservation, as the one in .text will be out of range as well;

- dynamic patching of the ftrace handler into .init.text code needs its
  own dedicated trampoline as the one in .text may be too far away.

- recent compilers may omit BTI veneers for static functions that never
  have their address taken, and so additional veneers will need to be
  added to .text in case cross-section direct branches from .init.text 
  require a PLT entry (and therefore a landing pad at the target end).

This is unfortunate, because it is actually somewhat unusual for .text
and .init.text to be so far away from each other: only when allocating
either of them (but not both) exhausts the 'near' (PLT-less) module
region, the other will be allocated from the spillover region, which is
not in direct branching range, and therefore requires PLT entries for
cross-section calls.

This series addresses this wart by allocating both of them as a single
chunk, and freeing the .init.text part along with the other init
sections at the appropriate time. This ensures that the two regions will
never require veneers for cross-section calls, allowing the arm64 module
loader to be simplified.

It looks like this should also be useful for ppc64, which currently
merges .init.text and .text because keeping them separate would require
stubs between the two, and consequently .init.text is never released in
modules on this architecture.

-- 
Thanks,
Petr