Hi Pablo, Thank you for your reply! On 24/01/2024 20:18, Pablo Neira Ayuso wrote: > On Wed, Jan 24, 2024 at 06:35:14PM +0000, Matthieu Baerts wrote: >> Hello, >> >> 24 Jan 2024 17:01:24 Jakub Kicinski <kuba@xxxxxxxxxx>: >> >>> On Wed, 24 Jan 2024 08:22:55 -0800 Jakub Kicinski wrote: >>>>> Going through the failing ksft-net series on >>>>> https://netdev.bots.linux.dev/status.html, all the tests I'm >>>>> responsible seem to be passing. >>>> >>>> Here's a more handy link filtered down to failures (clicking on >>>> the test counts links here): >>>> >>>> https://netdev.bots.linux.dev/contest.html?branch=net-next-2024-01-24--15-00&executor=vmksft-net-mp&pass=0 >>>> >>>> I have been attributing the udpg[rs]o and timestamp tests to you, >>>> but I haven't actually checked.. are they not yours? :) >>> >>> Ah, BTW, a major source of failures seems to be that iptables is >>> mapping to nftables on the executor. And either nftables doesn't >>> support the functionality the tests expect or we're missing configs :( >>> E.g. the TTL module. >> >> I don't know if it is the same issue, but for MPTCP, we use >> 'iptables-legacy' if available. >> >> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=0c4cd3f86a400 > > I'd suggest you do the other way around, first check if iptables-nft > is available, otherwise fall back to iptables-nft > > commit refers to 5.15 already have iptables-nft support, it should > work out of the box. 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. 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. 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. [1] https://lore.kernel.org/stable/ZAG8dla274kYfxoK@xxxxxxxxx/ [2] https://lore.kernel.org/netdev/20230609-upstream-net-20230610-mptcp-selftests-support-old-kernels-part-3-v1-0-2896fe2ee8a3@xxxxxxxxxxxx Cheers, Matt -- Sponsored by the NGI0 Core fund.
