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

["Ard Biesheuvel" <ardb@kernel.org>]

On Fri, 28 Aug 2026, at 15:07, Petr Pavlu wrote:
> 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 for the data point - are those stubs needed when there is some
distance between the placements of .text and .init.text?