armv7 R_ARM_PREL31 relocation out of range error when loading module
William Zhang
william.zhang at broadcom.com
Tue Sep 16 19:55:36 PDT 2025
Hi,
We recently ran into the driver loading error resulting from
apply_relocate function when it handle the R_ARM_PREL31 case in
arch/arm/kernel/module.c:
section 29 reloc 0 sym '': relocation 42 out of range (0xc2ab9be8 ->
0x7fad5998)
After some dig, it seems this issue is caused by this change:
ac3b43283923 ("module: replace module_layout with module_memory")
I can see the necessity of this change but it seems it can cause this
kind of error under certain configurations. In our particular case, we
use the 2G/2G split and our armv7 board has 1GB ddr memory. This means
the kernel lower memory is from 0x8000-0000 to 0xc000-0000 and vmalloc
range is from 0xc000-0000 and above.
Before this module layout change, the module is loaded through two
layout sections: core and init. The driver in the test is fairly big
and core module layout(text, data, rodata, sections) can not fit into
the 16MB MODULE memory so both text, data and rodata fallback to
vmalloc range. But with this change, it will text, data and rodata one
by one. So it ends up text in the MODULES memory but rodata is
allocated in VMALLOC and the distance is more than 1GB hence we
believe it causes the above error when R_ARM_PREL31 relocation can not
support more than 1GB offset.
Since the default split is 1G/3G model, the distance between vmalloc
and module memory is always below 1G so we won't see this issue. But
it seems to us the problem is real when use 2G/2G split.
It appears the sections containing R_ARM_PREL31 in our driver are
mostly in .ARM.exidx section. Some search shows this is used by ARM
C++ exception handling but our driver does not use C++. Is there a way
to disable such section for R_ARM_PREL31? If not, is there any
workaround or fix to handle this run-time R_ARM_PREL31 relocation
issue? The same apply_relocate function can handle R_ARM_JUMP24 out of
range using PLTS. Can this apply to R_ARM_PREL31?
Thanks in advance for any suggestions/comments/fixes.
Regards,
William
More information about the linux-arm-kernel
mailing list