From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next 2/2] netfilter: nf_tables: add packets conntrack state to debug trace info
Date: Wed, 21 May 2025 13:26:00 +0200 [thread overview]
Message-ID: <aC24SHR6Jl0uMhVl@strlen.de> (raw)
In-Reply-To: <aC2eUd6OOxn9ramP@calendula>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > + if (nla_put_be32(nlskb, NFT_CT_ID, (__force __be32)id))
> > + goto nla_put_failure;
> > +
> > + if (status && nla_put_be32(nlskb, NFT_CT_STATUS, htonl(status)))
> > + goto nla_put_failure;
>
> NFT_CT_* is enum nft_ct_keys which is not intended to be used as
> netlink attribute.
>
> NFT_CT_STATE is 0 which is usually reserved for _UNSPEC in netlink
> attribute definitions.
>
> My suggestion is that you define new attributes for this, it is
> boilerplate code to be added to uapi.
In that case I would prefer not to use NESTED attribute for this, i.e.:
* @NFTA_TRACE_CT_ID: connection tracking information (NLA_U32)
* @NFTA_TRACE_CT_STATUS: connection tracking information (NLA_U32)
* @NFTA_TRACE_CT_STATE: connection tracking information (NLA_U32)
... and so on. I see no potential for attribute re-use.
The only argument for NESTED is that userspace can check for presence
of NFTA_TRACE_CT/NESTED instead of checking each ct trace attr in
sequence.
Whats you preference?
next prev parent reply other threads:[~2025-05-21 11:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 15:08 [PATCH nf-next 0/2] netfilter: nf_tables: include conntrack state in trace messages Florian Westphal
2025-05-08 15:08 ` [PATCH nf-next 1/2] netfilter: conntrack: make nf_conntrack_id callable without a module dependency Florian Westphal
2025-05-08 15:08 ` [PATCH nf-next 2/2] netfilter: nf_tables: add packets conntrack state to debug trace info Florian Westphal
2025-05-21 9:35 ` Pablo Neira Ayuso
2025-05-21 11:26 ` Florian Westphal [this message]
2025-05-21 13:52 ` 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=aC24SHR6Jl0uMhVl@strlen.de \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/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.