Message-ID: <Zc+BYmrv/0pRKY+w@calendula>
Date: Fri, 16 Feb 2024 16:38:10 +0100
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Matthieu Baerts <matttbe@...nel.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,

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@

Powered by blists - more mailing lists