netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthieu Baerts <matttbe@kernel.org>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	netdev@vger.kernel.org, David Ahern <dsahern@kernel.org>,
	coreteam@netfilter.org, netdev-driver-reviewers@vger.kernel.org,
	Hangbin Liu <liuhangbin@gmail.com>,
	netfilter-devel@vger.kernel.org
Subject: Re: [netfilter-core] [ANN] net-next is OPEN
Date: Wed, 7 Feb 2024 12:33:44 +0100	[thread overview]
Message-ID: <51bdbaab-a611-4f4d-aa8c-e004102220f3@kernel.org> (raw)
In-Reply-To: <ZcNSPoqQkMBenwue@calendula>

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)?

>> 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.

>> 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!

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

  reply	other threads:[~2024-02-07 11:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240122091612.3f1a3e3d@kernel.org>
     [not found] ` <Za98C_rCH8iO_yaK@Laptop-X1>
     [not found]   ` <20240123072010.7be8fb83@kernel.org>
     [not found]     ` <d0e28c67-51ad-4da1-a6df-7ebdbd45cd2b@kernel.org>
     [not found]       ` <65b133e83f53e_225ba129414@willemb.c.googlers.com.notmuch>
     [not found]         ` <20240124082255.7c8f7c55@kernel.org>
2024-01-24 17:01           ` [ANN] net-next is OPEN Jakub Kicinski
2024-01-24 18:35             ` Matthieu Baerts
2024-01-24 19:00               ` Jakub Kicinski
2024-01-24 19:18               ` [netfilter-core] " Pablo Neira Ayuso
2024-02-06 18:31                 ` Matthieu Baerts
2024-02-07  9:49                   ` Pablo Neira Ayuso
2024-02-07 11:33                     ` Matthieu Baerts [this message]
2024-02-16 15:38                       ` Pablo Neira Ayuso
2024-02-16 15:51                         ` Matthieu Baerts
2024-01-24 19:16             ` Pablo Neira Ayuso
2024-01-24 19:40               ` Jakub Kicinski
2024-01-24 20:02                 ` Pablo Neira Ayuso
2024-01-24 20:13                   ` Jakub Kicinski
2024-01-25  5:07                     ` Jakub Kicinski
2024-01-25  8:52                       ` Florian Westphal
2024-01-25 17:30                         ` Jakub Kicinski
2024-01-25  9:29                       ` Pablo Neira Ayuso
2024-01-25 17:34                         ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51bdbaab-a611-4f4d-aa8c-e004102220f3@kernel.org \
    --to=matttbe@kernel.org \
    --cc=coreteam@netfilter.org \
    --cc=dsahern@kernel.org \
    --cc=kuba@kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=netdev-driver-reviewers@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).