Björn Töpel <bjorn.topel@xxxxxxxxx> writes: > On 2021-01-20 14:25, Björn Töpel wrote: >> On 2021-01-20 13:52, Toke Høiland-Jørgensen wrote: >>> Björn Töpel <bjorn.topel@xxxxxxxxx> writes: >>> >>>> From: Björn Töpel <bjorn.topel@xxxxxxxxx> >>>> >>>> Add detection for kernel version, and adapt the BPF program based on >>>> kernel support. This way, users will get the best possible performance >>>> from the BPF program. >>> >>> Please do explicit feature detection instead of relying on the kernel >>> version number; some distro kernels are known to have a creative notion >>> of their own version, which is not really related to the features they >>> actually support (I'm sure you know which one I'm referring to ;)). >>> >> >> Right. For a *new* helper, like bpf_redirect_xsk, we rely on rejection >> from the verifier to detect support. What about "bpf_redirect_map() now >> supports passing return value as flags"? Any ideas how to do that in a >> robust, non-version number-based scheme? >> > > Just so that I understand this correctly. Red^WSome distro vendors > backport the world, and call that franken kernel, say, 3.10. Is that > interpretation correct? My hope was that wasn't the case. :-( Yup, indeed. All kernels shipped for the entire lifetime of RHEL8 think they are v4.18.0... :/ I don't think we're the only ones doing it (there are examples in the embedded world as well, for instance, and not sure about the other enterprise distros), but RHEL is probably the most extreme example. We could patch the version check in the distro-supplied version of libbpf, of course, but that doesn't help anyone using upstream versions, and given the prevalence of vendoring libbpf, I fear that going with the version check will just result in a bad user experience... > Would it make sense with some kind of BPF-specific "supported > features" mechanism? Something else with a bigger scope (whole > kernel)? Heh, in my opinion, yeah. Seems like we'll finally get it for XDP, but for BPF in general the approach has always been probing AFAICT. For the particular case of arguments to helpers, I suppose the verifier could technically validate value ranges for flags arguments, say. That would be nice as an early reject anyway, but I'm not sure if it is possible to add after-the-fact without breaking existing programs because the verifier can't prove the argument is within the valid range. And of course it doesn't help you with compatibility with already-released kernels. -Toke
