Comment 25 for bug 1927076

Krzysztof mentioned that this has been found on 5.14 as well. Using a system he lent me (huggins), I also tested with the commit that changed the call to use CTR and it failed as well. But it always failed when __bpf_prog_run_save_cb was calling the jited bpf_func, and CTR always matched NIP (though in that case, it is the CTR from __bpf_prog_run_save_cb, not the JITed code). Sometimes it was NULL (all zeroes), sometimes it looked like a legit kernel address, and I got one 0xfe800000fe80000000 (or something like it), which looks like some corruption on bpf_prog.

Also, I noticed it doesn't happen always on CPU 0, which would be odd on its own. But it seems more likely. And it's either very hard to reproduce without doing the CPU hotplug or it is really necessary, and I left the program running on a loop for a long time and did not have any luck.

I also changed it to an eBPF program instead of cBPF, but still a socket filter type. And used get_smp_processor_id instead of the raw_processor_id (though I recall this being the same on ppc64el), and it still reproduced. And when I returned a constant instead of doing the call, it also reproduced. No wonder, as when it fails, the program never runs. But the way those programs are compiled makes no difference.

Cascardo.