Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: nft.ogxzcrqhuhgchbvxcs4j7wws@qmail.sunbirdgrove.com
Cc: netfilter@vger.kernel.org,
	netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: nft list sets changed behavior
Date: Sun, 18 Jun 2023 15:35:09 +0200	[thread overview]
Message-ID: <20230618133509.GA869@breakpoint.cc> (raw)
In-Reply-To: <962b1e4f-63e2-bc3b-bf27-5569c6402c0f@qmail.sunbirdgrove.com>

moving to nf-devel

nft.ogxzcrqhuhgchbvxcs4j7wws@qmail.sunbirdgrove.com <nft.ogxzcrqhuhgchbvxcs4j7wws@qmail.sunbirdgrove.com> wrote:
> Thanks for your reply. On Debian 11 it did list the elements for at least a
> year, that's why I'm surprised about this change. 0.9.8 vs. 1.0.6.
> 
> I'll look into filing a bug.

No need, consider the bug filed.

Pablo, we have a behaviour change in
"nft -j list sets".

1.0.0:
nft -j list sets : lists sets with elements.
nft list sets : no elements.

1.0.1+:
nft -j list sets : no elements.
nft list sets : no elements.

So 1.0.1+ it at least consistent, no set elements
are shown.

But it breaks at least one user setup:
> > > After updating to Debian 12 my tools relying on 'nft -j list sets' fail.
> > > It now does not include the elements in those lists like it did on 11.

I see three possible solutions:
1 - accept the breakage.
2 - repair the inconsistency so we get 1.0.0 and
    earlier behaviour back.
3 - make "list sets" *always* include set elements,
    unless --terse was given.

Thoughts? I'd go with 3, I dislike the
different behaviour that 2) implies and we already
have --terse, we just need to make use of it here.

I'd even favour 1 over 2.

This change came with
commit a1a6b0a5c3c4b4b305fa34a77932ee1c6452d1c8
cache: finer grain cache population for list commands

so it would be easy to resolve, e.g.:

diff --git a/src/cache.c b/src/cache.c
--- a/src/cache.c
+++ b/src/cache.c
@@ -235,6 +235,8 @@ static unsigned int evaluate_cache_list(struct nft_ctx *nft, struct cmd *cmd,
        case CMD_OBJ_SETS:
        case CMD_OBJ_MAPS:
                flags |= NFT_CACHE_TABLE | NFT_CACHE_SET;
+               if (!nft_output_terse(&nft->output))
+                       flags |= NFT_CACHE_SETELEM;
                break;
        case CMD_OBJ_FLOWTABLE:
                if (filter &&

  reply	other threads:[~2023-06-18 13:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-18  0:42 nft list sets changed behavior nft.ogxzcrqhuhgchbvxcs4j7wws
2023-06-18 11:22 ` Kerin Millar
2023-06-18 12:12   ` nft.ogxzcrqhuhgchbvxcs4j7wws
2023-06-18 13:35     ` Florian Westphal [this message]
2023-06-18 15:21       ` Pablo Neira Ayuso

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=20230618133509.GA869@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=netfilter@vger.kernel.org \
    --cc=nft.ogxzcrqhuhgchbvxcs4j7wws@qmail.sunbirdgrove.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