arm64: "unsupported RELA relocation: 275" loading certain modules
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Medium
|
|||
gcc-5 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Won't Fix
|
Undecided
|
Unassigned | ||
Zesty |
Won't Fix
|
Undecided
|
Unassigned | ||
gcc-6 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Invalid
|
Undecided
|
Unassigned | ||
Yakkety |
Won't Fix
|
Undecided
|
Unassigned | ||
Zesty |
Won't Fix
|
Undecided
|
Unassigned | ||
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Won't Fix
|
Undecided
|
Unassigned | ||
Zesty |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Certain kernel modules are unloadable (libceph & scsi_debug) due to the compiler generating unsupported relocations.
This symptom is similar to LP: #1533009 but, in that case it impacted all modules, and the fix for that appears to remain in place.
[Test Case]
With the hwe-z kernel:
ubuntu@grotian:~$ sudo modprobe libceph
modprobe: ERROR: could not insert 'libceph': Exec format error
ubuntu@grotian:~$ dmesg
[66988.470307] module libceph: unsupported RELA relocation: 275
[Regression Risk]
The scope of the fix is restricted to aarch64, so regressions should only impact the arm64 port of Ubuntu. Regressions could impact when literal loads are used - which may have performance impacts or possibly cause software to fail to build/run where it previously did. This is somewhat mitigated by the fact that this has been fixed in artful gcc-5/gcc-6 and used on our buildds for some time. Only "somewhat", because gcc-7 is now the default.
tags: | added: arm64 uosci |
Changed in linux: | |
importance: | Unknown → Medium |
status: | Unknown → In Progress |
Changed in gcc-6 (Ubuntu Xenial): | |
status: | Confirmed → Invalid |
Changed in gcc-5 (Ubuntu Xenial): | |
status: | New → Confirmed |
tags: | added: patch |
description: | updated |
Changed in linux (Ubuntu Xenial): | |
status: | Triaged → Fix Committed |
Changed in linux (Ubuntu Zesty): | |
status: | Triaged → Fix Committed |
Changed in linux (Ubuntu Zesty): | |
status: | Fix Committed → Won't Fix |
Changed in linux (Ubuntu Xenial): | |
status: | Fix Committed → Fix Released |
Changed in linux (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in gcc-6 (Ubuntu Zesty): | |
status: | Triaged → Won't Fix |
Changed in gcc-5 (Ubuntu Zesty): | |
status: | Triaged → Won't Fix |
Changed in linux: | |
status: | In Progress → Fix Released |
Created attachment 40487
test case to reproduce the problem
To support older Cortex A53 CPUs that suffer from erratum 843419 the Linux kernel has some option not to allow certain relocations in kernel modules. To achieve that it utilizes the options -mcmodel=large -mpc-relative- literal- loads.
Unfortunately we found a case where gcc does still produce such relocations despite the options being used if optimization level is at least -O2.
The code in question is attached and the problem can be reproduced like this:
$ aarch64- linux-gnu- gcc -O2 -mcmodel=large -mpc-relative- literal- loads -c t.c linux-gnu- objdump -r t.o
$ aarch64-
t.o: file format elf64-littleaarch64
RELOCATION RECORDS FOR [.text]: ADR_PREL_ PG_HI21 .text+0x0000000 000000060 ADD_ABS_ LO12_NC .text+0x0000000 000000060
OFFSET TYPE VALUE
0000000000000018 R_AARCH64_CALL26 strcmp
0000000000000030 R_AARCH64_
0000000000000034 R_AARCH64_
0000000000000050 R_AARCH64_ABS64 .rodata.str1.8
Obviously the attached code by itself might not be very useful but it is a stripped-down code example of a real-world kernel driver just to demonstrate the problem.
Some observations:
1. The problem did reproduce with the latest patches from Linaro and with the upstream version (without the Linaro patches) of latest gcc 6 branch.
2. The problem did also reproduce with the gcc 5 branch including the Linaro patches on that branch. I did not check the gcc 5 branch without the Linaro patches.
3. The problem disappears if the useless (not used in the code) second entry in the array gets removed from the code.
4. The problem seems to be in the code that is generated for the strcpy by the compiler.
5. The problem disappears if the string is made longer. In that case the string ends up in .rodata.str1.8 section like the other string, while in the problematic case it is stored as .xword type in .text section.
So my personal conclusion is that some code in the backend involved in this strcpy optimization does not honor the -mpc-relative- literal- loads option properly.