>> The bad-commit mentioned in "the Fixes tag":
>> Fixes: a23740ec43ba ("bpf: Track contents of read-only maps as scalars")
>> Which as you say, could well have been fixing another issue.
>> In fact, yes it was:
>> https://lore.kernel.org/stable/20210821203108.215937-2-rafaeldtinoco@xxxxxxxxx/
>> Daniel, what do you suggest please?
>
> Hm, okay, so a23740ec43ba ("bpf: Track contents of read-only maps as scalars") was
> backported to 5.4.144 given Rafael needed it to fix a failing regression test [0].
>
> Normally, I would have said that we should just revert a23740ec43ba given it was
> not a 'fix' in the first place, but then we are getting into a situation where it
> would break Rafael's now functioning test case again on 5.4.144+ released kernels.
>
IIRC, Without this patch, eBPF programs with extern variables, either from ksyms
or kconfig relocations, done by libbpf, used as branch conditions, won't work in
<= 5.4.144.
Something like:
extern u32 CONFIG_ARCH_HAS_SYSCALL_WRAPPER __kconfig;
...
if (CONFIG_ARCH_HAS_SYSCALL_WRAPPER) {
valid BTF type declared/used
} else {
<dead code>: invalid BTF type declared/used
}
...
The dead code is always evaluated and object load does not pass the verifier.
The workaround to mitigate this is to always rely in type/field existence checks
for the branch conditions, instead of relying in kconfig/ksyms relocations.
We've been doing this to support same CO-RE BPF obj in kernels < 5.4 so I guess
we could continue doing this for 5.4 as well (allowing you to drop this "fix").
Sorry for the burden (about having to introduce another fix, needed because of
that patch). I hope nobody else is relying on it and, if they are, there is a
mitigation described above.
So, feel free to drop it if it's easier for 5.4 maintenance, I'll mitigate
code on our side.
And, Thanks a lot for checking!
> Rafael, given you need this, do you have some cycles to help out Lee on this backport
> for 5.4 stable?
>
> Thanks guys,
> Daniel
>
> [0] https://lore.kernel.org/stable/20210821203108.215937-1-rafaeldtinoco@xxxxxxxxx/
