Hi Matthieu, On Tue, Feb 06, 2024 at 07:31:44PM +0100, Matthieu Baerts wrote: [...] > Good point, I understand it sounds better to use 'iptables-nft' in new > kselftests. I should have added a bit of background and not just a link > to this commit: at that time (around ~v6.4), we didn't need to force > using 'iptables-legacy' on -net or net-next tree. But we needed that > when testing kernels <= v5.15. > > When validating (old) stable kernels, the recommended practice is > apparently [1] to use the kselftests from the last stable version, e.g. > using the kselftests from v6.7.4 when validating kernel v5.15.148. The > kselftests are then supposed to support older kernels, e.g. by skipping > some parts if a feature is not available. I didn't know about that > before, and I don't know if all kselftests devs know about that. We are sending backports to stable kernels, if one stable kernel fails, then we have to fix it. > I don't think that's easy to support old kernels, especially in the > networking area, where some features/behaviours are not directly exposed > to the userspace. Some MPTCP kselftests have to look at /proc/kallsyms > or use other (ugly?) workarounds [2] to predict what we are supposed to > have, depending on the kernel that is being used. But something has to > be done, not to have big kselftests, with many different subtests, > always marked as "failed" when validating new stable releases. iptables-nft is supported in all of the existing stable kernels. > Back to the modification to use 'iptables-legacy', maybe a kernel config > was missing, but the same kselftest, with the same list of kconfig to > add, was not working with the v5.15 kernel, while everything was OK with > a v6.4 one. With 'iptables-legacy', the test was running fine on both. I > will check if maybe an old kconfig option was not missing. I suspect this is most likely kernel config missing, as it happened to Jakub. Thanks.
