On Mon, Jul 03, 2023 at 12:03:38PM +0200, Arnd Bergmann wrote:
On Mon, Jul 3, 2023, at 11:51, Mark Rutland wrote:
On Mon, Jul 03, 2023 at 12:02:22PM +0530, Naresh Kamboju wrote:
On Sun, 2 Jul 2023 at 13:56, Arnd Bergmann arnd@arndb.de wrote:
On Sat, Jul 1, 2023, at 10:42, Naresh Kamboju wrote:
Here is the build artifacts location with kselftest merge configs. https://storage.tuxsuite.com/public/linaro/lkft/builds/2Rum1V78RQJMftEanwtN2...
In your .config here, I note you have:
| CONFIG_UBSAN_TRAP=y
Can you try this with CONFIG_UBSAN_TRAP=n ?
[ 56.150153] Modules linked in: crct10dif_ce sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 cfg80211 bluetooth rfkill sch_fq_codel fuse drm [ 56.151781] CPU: 0 PID: 438 Comm: seccomp_bpf Not tainted 6.4.0 #1 [ 56.152043] Hardware name: linux,dummy-virt (DT) [ 56.152396] pstate: 41400005 (nZcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 56.152667] pc : alloc_pid+0x3b4/0x3c8 [ 56.154243] lr : alloc_pid+0x140/0x3c8
Looking at objdump, that's:
| ffff8000800d73b0 <alloc_pid>: | ... | ffff8000800d7764: d4207d00 brk #0x3e8
... and addr2line fingers this as:
| [mark@lakrids:~/tmp-naresh-kamboju]% usekorg 10.3.0 aarch64-linux-addr2line -ife vmlinux ffff8000800d7764 | alloc_pid | /builds/linux/kernel/pid.c:244
... which appears to be:
| 244 pid->numbers[i].nr = nr;
Full objdump of the function below; as above I suspect this is UBSAN triggering a __builtin_trap() on an out-of-range access.
It looks like a fix has already made it into mainline now, so it should be fixed on the latest linux-next:
https://lore.kernel.org/lkml/20230630180418.gonna.286-kees@kernel.org/
Thanks for the pointer!
Mark.