Message-ID: <7a1014ee-7e1d-4be4-bab2-07ddde8a84b7@kernel.org>
Date: Tue, 6 Feb 2024 19:31:44 +0100
From: Matthieu Baerts <matttbe@...nel.org>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Jakub Kicinski <kuba@...nel.org>,
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, netdev@...r.kernel.org,
 David Ahern <dsahern@...nel.org>, coreteam@...filter.org,
 netdev-driver-reviewers@...r.kernel.org, Hangbin Liu <liuhangbin@...il.com>,
 netfilter-devel@...r.kernel.org
Subject: Re: [netfilter-core] [ANN] net-next is OPEN

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@...nel.org>:
>>
>>> 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@kroah.com/
[2]
https://lore.kernel.org/netdev/20230609-upstream-net-20230610-mptcp-selftests-support-old-kernels-part-3-v1-0-2896fe2ee8a3@tessares.net

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Powered by blists - more mailing lists