Hi Pablo, Thank you for your reply! On 16/02/2024 16:38, Pablo Neira Ayuso wrote: > 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. That's great! It is good to support all the different kernels. >>>> 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. We were probably unlucky and hit a kernel/userspace bug that has been fixed in between, sorry for the noise! >>>> 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@ Will do, thank you! Cheers, Matt -- Sponsored by the NGI0 Core fund.
