All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Matthieu Baerts <matttbe@kernel.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 10:49:50 +0100	[thread overview]
Message-ID: <ZcNSPoqQkMBenwue@calendula> (raw)
In-Reply-To: <7a1014ee-7e1d-4be4-bab2-07ddde8a84b7@kernel.org>

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.

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

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

Thanks.

  reply	other threads:[~2024-02-07  9:49 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22 17:16 [ANN] net-next is OPEN Jakub Kicinski
2024-01-22 20:54 ` Simon Horman
2024-01-23  8:45 ` Hangbin Liu
2024-01-23 15:20   ` Jakub Kicinski
2024-01-23 16:51     ` David Ahern
2024-01-23 21:39       ` Jakub Kicinski
2024-01-24  5:20         ` David Ahern
2024-01-24  8:22           ` Paolo Abeni
2024-01-24 15:07             ` Jakub Kicinski
2024-01-24 16:19               ` Jakub Kicinski
2024-01-24 16:35                 ` David Ahern
2024-01-24 16:59                   ` Jakub Kicinski
2024-01-24 21:48                     ` David Ahern
2024-01-27  0:56                       ` David Ahern
2024-01-27  1:13                         ` Jakub Kicinski
2024-01-28  4:26                           ` David Ahern
2024-01-29  9:23                             ` Paolo Abeni
2024-01-29 15:03                               ` Jakub Kicinski
2024-01-29 15:32                                 ` David Ahern
2024-01-29 16:53                                   ` Jakub Kicinski
2024-01-24 15:59       ` Willem de Bruijn
2024-01-24 16:22         ` Jakub Kicinski
2024-01-24 17:01           ` 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 [this message]
2024-02-07 11:33                     ` Matthieu Baerts
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
2024-01-24 17:42           ` Willem de Bruijn
2024-01-24 17:49             ` Jakub Kicinski
2024-01-24 18:23               ` Willem de Bruijn
2024-01-24 18:31                 ` Paolo Abeni
2024-01-23  9:55 ` Petr Machata
2024-01-23 12:42   ` Matthias May
2024-01-23 13:38     ` Petr Machata
2024-01-23 15:30       ` Jakub Kicinski
2024-01-23 16:05         ` Petr Machata
2024-01-23 16:33           ` Jakub Kicinski
2024-01-23 15:34   ` Jakub Kicinski
2024-01-23 17:04     ` Petr Machata
2024-01-23 17:38       ` Jakub Kicinski
2024-01-24 11:06         ` Petr Machata
2024-01-29 12:43 ` Ido Schimmel
2024-01-29 12:46   ` Ido Schimmel
2024-01-29 15:00     ` Jakub Kicinski
2024-01-29 17:00       ` Ido Schimmel
2024-01-29 17:18         ` Jakub Kicinski
2024-01-31 13:23           ` Ido Schimmel
2024-01-31 14:16             ` Heiner Kallweit
2024-01-31 16:01             ` [TEST] bridge tests (was: net-next is OPEN) Jakub Kicinski
2024-02-01 13:46               ` Ido Schimmel
2024-02-01 15:30                 ` Jakub Kicinski
2024-02-02  0:16                   ` Jakub Kicinski
2024-02-08 16:21                     ` Ido Schimmel
2024-02-08 17:26                       ` 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=ZcNSPoqQkMBenwue@calendula \
    --to=pablo@netfilter.org \
    --cc=coreteam@netfilter.org \
    --cc=dsahern@kernel.org \
    --cc=kuba@kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=matttbe@kernel.org \
    --cc=netdev-driver-reviewers@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.