On Sun, Aug 16, 2026 at 04:49:59PM +0300, Ard Biesheuvel wrote: > On Sun, 16 Aug 2026, at 12:41, Will Deacon wrote: > > Overall, it seems to me like there are three cases we need to consider > > for re-enabling BTI in the kernel: > > > > 1. A cross-section call that spans beyond the 128M range and therefore > > needs a veneer. I think the static linker should resolve this, probably > > by emitting a second veneer with the landing pad. Do we know if LLD > > gets this right? > > > > There are two variants here: > > A cross-section call .init.text to .text that spans beyond the 128M range: > > 1a. inside vmlinux, which should be dealt with by the linker, but which might > be unreliable in practice due to the lack of BTI annotations in asm files, > missing exec permissions on ELF sections etc. This is addressed by this > series, > but is only an issue for unusually large kernel images (e.g., allyesconfig).
Right, and if we don't care about the >128MB kernel case (I have no idea if anybody actually uses that big of a kernel?), then we can basically just drop patches 3-11 in favor of a simple linker assertion (similar to patches 5 and 6) which just *always* triggers a build error on a large kernel + BTI + !COMPILE_TEST. -- Josh
