Hi, Sorry for taking a while. On Wed, Feb 07, 2024 at 12:33:44PM +0100, Matthieu Baerts wrote: > Hi Pablo, > > Thank you for your reply! > > On 07/02/2024 10:49, Pablo Neira Ayuso wrote: > > 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. > > Do you validate stable kernels by running the kselftests from the same > version (e.g. both from v5.15.x) or by using the kselftests from the > last stable one (e.g. kernel v5.15.148 validated using the kselftests > from v6.7.4)? We have kselftests, but nftables/tests/shell probe for kernel capabilities then it runs tests according to what the kernel supports, this includes packet and control plane path tests. For iptables, there are iptables-tests.py for the control plane path. > >> 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. > > OK, then we should not have had the bug we had. I thought we were using > features that were not supported in v5.15. I don't think so, iptables-nft supports the same features as iptables-legacy. > >> 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. > > Probably, yes. I just retried by testing a v5.15.148 kernel using the > kselftests from the net-next tree and forcing iptables-nft: I no longer > have the issue I had one year ago. Not sure why, we already had > NFT_COMPAT=m back then. Maybe because we recently added IP_NF_FILTER and > similar, because we noticed some CI didn't have them? > Anyway, I will then switch back to iptables-nft. Thanks for the suggestion! Thanks. If you experience any issue, report back to netfilter-devel@
