netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [nf PATCH v2 7/8] netfilter: nf_tables: Pass reset bit in nft_set_dump_ctx
Date: Fri, 29 Sep 2023 13:12:30 +0200	[thread overview]
Message-ID: <ZRaxHlrhNsBBrLC6@orbyte.nwl.cc> (raw)
In-Reply-To: <ZRatT4q729r7MPBO@calendula>

On Fri, Sep 29, 2023 at 12:56:15PM +0200, Pablo Neira Ayuso wrote:
> On Fri, Sep 29, 2023 at 12:18:28PM +0200, Phil Sutter wrote:
> > On Fri, Sep 29, 2023 at 12:15:16PM +0200, Pablo Neira Ayuso wrote:
> > > On Fri, Sep 29, 2023 at 12:08:18PM +0200, Phil Sutter wrote:
> > > > On Thu, Sep 28, 2023 at 08:53:11PM +0200, Pablo Neira Ayuso wrote:
> > > > > On Thu, Sep 28, 2023 at 06:52:43PM +0200, Phil Sutter wrote:
> > > > > > Relieve the dump callback from having to check nlmsg_type upon each
> > > > > > call. Prep work for set element reset locking.
> > > > > 
> > > > > Maybe add this as a preparation patch first place in this series,
> > > > > rather making this cleanup at this late stage of the batch.
> > > > 
> > > > Sure, no problem. I extracted it from v1 of patch 8 and so they are
> > > > closely related.
> > > > 
> > > > Maybe I should split the series up in per-callback ones? I'd start with
> > > > the getsetelem_reset one as that is most cumbersome it seems.
> > > 
> > > Thanks.
> > > 
> > > Side note: I also read a comment from Florian regarding the use of
> > > ctx.table. You have to be very careful with what you cache in the dump
> > > context area, since such pointer might just go away.
> > > 
> > > So far this code caches was "careful" to cache only to check if the
> > > table was still there, but iterating over the table list again
> > > (another safer approach could be to use the table handle which is
> > > unique).
> > > 
> > > All this is also related to the chunked nature of netlink dumps
> > > (in other words, userspace retrieves part of it in every
> > > netlink_recvmsg() call).
> > 
> > Good point. I think we may reduce all this to 'strdup(table->name)' and
> > not care what happens in other CPUs. The only requirement is to cache
> > table->family for audit logging also (IIRC). I'll give this a try.
> 
> table handle is u64 and you don't need to clone, right? Handle
> allocation is monotonic.

The intention was to use it for audit logging as well which requires the
name (and family). Pulling anything that accesses the cached data into
the critical section is probably more straightforward.

  reply	other threads:[~2023-09-29 11:12 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28 16:52 [nf PATCH v2 0/8] Introduce locking for reset requests Phil Sutter
2023-09-28 16:52 ` [nf PATCH v2 1/8] netfilter: nf_tables: Don't allocate nft_rule_dump_ctx Phil Sutter
2023-09-28 18:49   ` Pablo Neira Ayuso
2023-09-29 10:15     ` Phil Sutter
2023-09-28 19:00   ` Florian Westphal
2023-09-29 10:13     ` Phil Sutter
2023-09-28 16:52 ` [nf PATCH v2 2/8] netfilter: nf_tables: Introduce nf_tables_getrule_single() Phil Sutter
2023-09-28 16:52 ` [nf PATCH v2 3/8] netfilter: nf_tables: Add locking for NFT_MSG_GETRULE_RESET requests Phil Sutter
2023-09-28 16:52 ` [nf PATCH v2 4/8] netfilter: nf_tables: Introduce struct nft_obj_dump_ctx Phil Sutter
2023-09-28 16:52 ` [nf PATCH v2 5/8] netfilter: nf_tables: Introduce nf_tables_getobj_single Phil Sutter
2023-09-28 16:52 ` [nf PATCH v2 6/8] netfilter: nf_tables: Add locking for NFT_MSG_GETOBJ_RESET requests Phil Sutter
2023-09-28 16:52 ` [nf PATCH v2 7/8] netfilter: nf_tables: Pass reset bit in nft_set_dump_ctx Phil Sutter
2023-09-28 18:53   ` Pablo Neira Ayuso
2023-09-29 10:08     ` Phil Sutter
2023-09-29 10:15       ` Pablo Neira Ayuso
2023-09-29 10:18         ` Phil Sutter
2023-09-29 10:56           ` Pablo Neira Ayuso
2023-09-29 11:12             ` Phil Sutter [this message]
2023-09-28 16:52 ` [nf PATCH v2 8/8] netfilter: nf_tables: Add locking for NFT_MSG_GETSETELEM_RESET requests Phil Sutter
2023-09-28 17:46   ` Florian Westphal
2023-09-28 18:47     ` Pablo Neira Ayuso
2023-09-28 18:57       ` Florian Westphal
2023-09-28 19:04         ` Pablo Neira Ayuso
2023-09-28 19:21           ` Florian Westphal
2023-09-28 20:07             ` Florian Westphal
2023-09-29 11:25               ` Phil Sutter
2023-09-29 11:30                 ` Florian Westphal
2023-09-29 11:45                   ` Phil Sutter
2023-09-28 19:39           ` Jozsef Kadlecsik
2023-09-28 20:09             ` Florian Westphal
2023-09-28 20:25               ` Jozsef Kadlecsik
2023-09-29 11:03     ` Phil Sutter
2023-09-28 18:51   ` Pablo Neira Ayuso
2023-09-29 10:28     ` Phil Sutter

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=ZRaxHlrhNsBBrLC6@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=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 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).