From: Thomas Haller <thaller@redhat.com>
To: Phil Sutter <phil@nwl.cc>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
Florian Westphal <fw@strlen.de>,
NetFilter <netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH nft v3 2/6] tests/shell: check and generate JSON dump files
Date: Fri, 17 Nov 2023 18:23:35 +0100 [thread overview]
Message-ID: <859777cb74f7edb825c71dd1d01ae976c8416551.camel@redhat.com> (raw)
In-Reply-To: <ZVeesPraB1QucCEG@orbyte.nwl.cc>
On Fri, 2023-11-17 at 18:11 +0100, Phil Sutter wrote:
> On Fri, Nov 17, 2023 at 06:06:16PM +0100, Thomas Haller wrote:
> > On Fri, 2023-11-17 at 17:57 +0100, Phil Sutter wrote:
> > > On Fri, Nov 17, 2023 at 05:36:23PM +0100, Pablo Neira Ayuso
> > > wrote:
> > > > On Fri, Nov 17, 2023 at 05:16:02PM +0100, Thomas Haller wrote:
> > > > > On Fri, 2023-11-17 at 00:00 +0100, Florian Westphal wrote:
> > > > > > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > > > > > Hi Thomas,
> > > > > > >
> > > > > > > On Wed, Nov 15, 2023 at 01:36:40PM +0100, Thomas Haller
> > > > > > > wrote:
> > > > > > > > On Wed, 2023-11-15 at 13:30 +0100, Pablo Neira Ayuso
> > > > > > > > wrote:
> > > > > > > [...]
> > > > > > > > > I see _lots_ of DUMP FAIL with kernel 5.4
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Could you provide more details?
> > > > > > > >
> > > > > > > > For example,
> > > > > > > >
> > > > > > > > make -j && ./tests/shell/run-tests.sh
> > > > > > > > tests/shell/testcases/include/0007glob_double_0 -x
> > > > > > > > grep ^ -a -R /tmp/nft-test.latest.*/
> > > > > > >
> > > > > > > # cat [...]/ruleset-diff.json
> > > > > > > --- testcases/include/dumps/0007glob_double_0.json-nft
> > > > > > > 2023-
> > > > > > > 11-15
> > > > > > > 13:27:20.272084254 +0100
> > > > > > > +++ /tmp/nft-test.20231116-170617.584.lrZzMy/test-
> > > > > > > testcases-
> > > > > > > include-0007glob_double_0.1/ruleset-after.json 2023-
> > > > > > > 11-
> > > > > > > 16
> > > > > > > 17:06:18.332535411 +0100
> > > > > > > @@ -1 +1 @@
> > > > > > > -{"nftables": [{"metainfo": {"version": "VERSION",
> > > > > > > "release_name":
> > > > > > > "RELEASE_NAME", "json_schema_version": 1}}, {"table":
> > > > > > > {"family":
> > > > > > > "ip", "name": "x", "handle": 1}}, {"table": {"family":
> > > > > > > "ip",
> > > > > > > "name": "y", "handle": 2}}]}
> > > > > > > +{"nftables": [{"metainfo": {"version": "VERSION",
> > > > > > > "release_name":
> > > > > > > "RELEASE_NAME", "json_schema_version": 1}}, {"table":
> > > > > > > {"family":
> > > > > > > "ip", "name": "x", "handle": 158}}, {"table": {"family":
> > > > > > > "ip",
> > > > > > > "name": "y", "handle": 159}}]}
> > > > > > >
> > > > > > > It seems that handles are a problem in this diff.
> > > > > >
> > > > > > Are you running tests with -s option?
> > > > > >
> > > > > > In that case, modules are removed after each test.
> > > > > >
> > > > > > I suspect its because we can then hit -EAGAIN mid-
> > > > > > transaction
> > > > > > because module is missing (again), then replay logic does
> > > > > > its
> > > > > > thing.
> > > > > >
> > > > > > But the handle generator isn't transaction aware,
> > > > > > so it has advanced vs. the aborted partial transaction.
> > > > >
> > > > > > I'm not sure what to do here.
> > > > >
> > > > > a combination of:
> > > > >
> > > > > a) make an effort, that kernel behavior is consistent and
> > > > > reproducible.
> > > > > Stable output seems important to me, and the automatic
> > > > > loading of
> > > > > a
> > > > > kernel module should not make a difference. This is IMO a
> > > > > bug.
> > > >
> > > > This is not a bug in the kernel. The kernel guarantees that the
> > > > handle
> > > > is unique, but the handle allocation strategy is up to the
> > > > kernel.
> > > > Userspace cannot forecast what handle will get, such thing
> > > > might
> > > > lead
> > > > to easy to break assumptions from userspace.
> > > >
> > > > > b) let `nft -j list ruleset` honor (the lack of) `--handle`
> > > > > option and
> > > > > not print those handles. That bugfix would change behavior,
> > > > > so
> > > > > maybe
> > > > > instead add a "--no-handle" option for `nft -j` dumps.
> > >
> > >
> > > >
> > > > Will honoring -a/--handle break firewalld? I think it is the
> > > > main
> > > > user
> > > > of the JSON API. That might help disentangle if this makes
> > > > sense or
> > > > not and what the chances of breaking third party applications
> > > > are.
> > > >
> > > > I'd prefer not to see a --no-handle that will only work for
> > > > JSON
> > > > and
> > > > that is only useful for this test infrastructure (noone else
> > > > asked
> > > > for
> > > > this).
> > > >
> > > > > c) sanitize the output with the sed command (my other mail).
> > > > >
> > > > > This also means, that the .json-nft dumps won't work, if you
> > > > > run
> > > > > without `unshare`. IMO, the mode without unshare should not
> > > > > be
> > > > > supported anymore. But if it's deemed important, then it
> > > > > requires
> > > > > b) or
> > > > > c) or detect the case and skip the diffs with .json-nft.
> > >
> > > What is the problem without unshare? Looking at your patch, it
> > > seems
> > > possible to drop the handle attributes in json-sanitize-
> > > ruleset.sh.
> >
> > Yes, (b) would suffice. I said "or" :)
> >
> > No further problem, but without-unshare seems not a useful thing to
> > support. The test-run takes significantly longer, interferes with
> > the
> > caller's netns and requires CAP_NET_ADMIN.
>
> No, I was wondering why with option (c) "This also means, that the
> .json-nft dumps won't work, if you run without `unshare`."
>
> Because I vote for that option. ;)
Yes, sorry. I got confused with my own numbering :)
I meant also c)
> > >
> > > > a) is no-go (kernel update to make test infrastructure or to
> > > > allow
> > > > userspace application to make fragile assumptions on how
> > > > handles
> > > > are
> > > > allocated is not correct).
> > > >
> > > > b) needs to evaluated, you maintain firewalld, let us know.
> > >
> > > Given the inherent importance of the handle value for ruleset
> > > manipulations, I assume *any* application will need to be updated
> > > to
> > > pass --handle (or the libnftables-equivalent) to remain
> > > functional.
> >
> > Right. So a "--no-handle" / NFT_CTX_OUTPUT_NO_HANDLE flag for JSON
> > output?
>
> Should not be needed. IIUC, the test infrastructure you're about to
> introduce sanitizes the JSON output already anyway, right?
Right. c) alone may very well suffice.
I just sent a patch to that amount.
I still think that `nft -j` ignoring the lack of "--no-handle" /
NFT_CTX_OUTPUT_NO_HANDLE is a bug. At the very last a documentation
bug.
Thomas
next prev parent reply other threads:[~2023-11-17 17:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 15:29 [PATCH nft v3 0/6] add and check dump files for JSON in tests/shell Thomas Haller
2023-11-14 15:29 ` [PATCH nft v3 1/6] json: fix use after free in table_flags_json() Thomas Haller
2023-11-15 9:58 ` Pablo Neira Ayuso
2023-11-14 16:08 ` [PATCH nft v3 2/6] tests/shell: check and generate JSON dump files Thomas Haller
2023-11-14 16:08 ` [PATCH nft v3 4/6] tools: simplify error handling in "check-tree.sh" by adding msg_err()/msg_warn() Thomas Haller
2023-11-14 16:08 ` [PATCH nft v3 5/6] tools: check more strictly for bash shebang in "check-tree.sh" Thomas Haller
2023-11-14 16:08 ` [PATCH nft v3 6/6] tools: check for consistency of .json-nft dumps " Thomas Haller
2023-11-15 8:24 ` [PATCH nft v3 2/6] tests/shell: check and generate JSON dump files Florian Westphal
2023-11-15 9:54 ` Pablo Neira Ayuso
2023-11-15 10:01 ` Florian Westphal
2023-11-15 10:05 ` Pablo Neira Ayuso
2023-11-15 10:10 ` Florian Westphal
2023-11-15 10:26 ` Pablo Neira Ayuso
2023-11-15 10:31 ` Florian Westphal
2023-11-15 10:35 ` Pablo Neira Ayuso
2023-11-15 10:43 ` Pablo Neira Ayuso
2023-11-15 12:21 ` Florian Westphal
2023-11-15 12:30 ` Pablo Neira Ayuso
2023-11-15 12:36 ` Thomas Haller
2023-11-16 16:10 ` Pablo Neira Ayuso
2023-11-16 16:49 ` Thomas Haller
2023-11-16 16:55 ` Thomas Haller
2023-11-16 23:00 ` Florian Westphal
2023-11-16 23:02 ` Florian Westphal
2023-11-17 8:27 ` Pablo Neira Ayuso
2023-11-17 16:16 ` Thomas Haller
2023-11-17 16:36 ` Pablo Neira Ayuso
2023-11-17 16:56 ` Thomas Haller
2023-11-17 16:57 ` Phil Sutter
2023-11-17 17:06 ` Thomas Haller
2023-11-17 17:11 ` Phil Sutter
2023-11-17 17:23 ` Thomas Haller [this message]
2023-11-17 22:30 ` Phil Sutter
2023-11-15 10:11 ` Thomas Haller
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=859777cb74f7edb825c71dd1d01ae976c8416551.camel@redhat.com \
--to=thaller@redhat.com \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/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).