On Mon, Jul 01, 2024 at 11:46:59AM +0000, Puranjay Mohan wrote: > From: Russell King <russell.king@xxxxxxxxxx> > > [ Upstream commit b89ddf4cca43f1269093942cf5c4e457fd45c335 ] > > Commit 91fc957c9b1d ("arm64/bpf: don't allocate BPF JIT programs in module > memory") restricts BPF JIT program allocation to a 128MB region to ensure > BPF programs are still in branching range of each other. However this > restriction should not apply to the aarch64 JIT, since BPF_JMP | BPF_CALL > are implemented as a 64-bit move into a register and then a BLR instruction - > which has the effect of being able to call anything without proximity > limitation. > > The practical reason to relax this restriction on JIT memory is that 128MB of > JIT memory can be quickly exhausted, especially where PAGE_SIZE is 64KB - one > page is needed per program. In cases where seccomp filters are applied to > multiple VMs on VM launch - such filters are classic BPF but converted to > BPF - this can severely limit the number of VMs that can be launched. In a > world where we support BPF JIT always on, turning off the JIT isn't always an > option either. > > Fixes: 91fc957c9b1d ("arm64/bpf: don't allocate BPF JIT programs in module memory") > Suggested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > Signed-off-by: Russell King <russell.king@xxxxxxxxxx> > Signed-off-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx> > Tested-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > Link: https://lore.kernel.org/bpf/1636131046-5982-2-git-send-email-alan.maguire@xxxxxxxxxx > [Replace usage of in_bpf_jit() with is_bpf_text_address()] > Signed-off-by: Puranjay Mohan <pjy@xxxxxxxxxx> > --- > arch/arm64/include/asm/extable.h | 9 --------- > arch/arm64/include/asm/memory.h | 5 +---- > arch/arm64/kernel/traps.c | 2 +- > arch/arm64/mm/extable.c | 3 ++- > arch/arm64/mm/ptdump.c | 2 -- > arch/arm64/net/bpf_jit_comp.c | 7 ++----- > 6 files changed, 6 insertions(+), 22 deletions(-) > This is reported to cause problems: https://lore.kernel.org/r/CA+G9fYtfAbfcQ9J9Hzq-e6yoBVG3t_iHZ=bS2eJbO_aiOcquXQ@xxxxxxxxxxxxxx so I will drop it now. How did you test this? And if you really need this feature, why not move to a more modern kernel version? thanks, greg k-h