netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Fernando Fernandez Mancera <ffmancera@riseup.net>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 1/2 nf-next v2] netfilter: nf_tables: Introduce stateful object update operation
Date: Sat, 24 Aug 2019 18:29:34 +0200	[thread overview]
Message-ID: <20190824162934.sdlrz56out4tzlw7@salvia> (raw)
In-Reply-To: <20d36122-4d8d-e73f-a5d9-af1642d3a887@riseup.net>

On Fri, Aug 23, 2019 at 08:28:46PM +0200, Fernando Fernandez Mancera wrote:
> On 8/23/19 8:05 PM, Fernando Fernandez Mancera wrote:
> > 
> > 
> > On 8/23/19 2:42 PM, Pablo Neira Ayuso wrote:
> >> On Fri, Aug 23, 2019 at 02:41:42PM +0200, Pablo Neira Ayuso wrote:
> >>> On Thu, Aug 22, 2019 at 06:48:26PM +0200, Fernando Fernandez Mancera wrote:
> >>>> @@ -1405,10 +1409,16 @@ struct nft_trans_elem {
> >>>>  
> >>>>  struct nft_trans_obj {
> >>>>  	struct nft_object		*obj;
> >>>> +	struct nlattr			**tb;
> >>>
> >>> Instead of annotatint tb[] on the object, you can probably add here:
> >>>
> >>> union {
> >>>         struct quota {
> >>>                 uint64_t                consumed;
> >>>                 uint64_t                quota;
> >>>       } quota;
> >>> };
> >>>
> >>> So the initial update annotates the values in the transaction.
> >>>
> 
> If we follow that pattern then the indirection would need the
> nft_trans_phase enum, the quota struct and also the tb[] as parameters
> because in the preparation phase we always need the tb[] array.

Right, so this is my next idea :-)

For the update case, I'd suggest you use the existing 'obj' field in
the transaction object. The idea would be to allocate a new object via
nft_obj_init() from the update path. Hence, you can use the existing
expr->ops->init() interface to parse the attributes - I find the
existing parsing for ->update() a bit redundant.

Then, from the commit path, you use the new ->update() interface to
update the object accordingly taking this new object as input. I think
you cannot update u64 quota like you do in this patch. On 32-bit
arches, an assignment of u64 won't be atomic. So you have to use
atomic64_set() and atomic64_read() to make sure that packet path does
not observes an inconsistent state. BTW, once you have updated the
existing object, you can just release the object in the transaction
coming in this update. I think you will need a 'bool update' field on
the transaction object, so the commit path knows how to handle the
update.

  reply	other threads:[~2019-08-24 16:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-22 16:48 [PATCH 1/2 nf-next v2] netfilter: nf_tables: Introduce stateful object update operation Fernando Fernandez Mancera
2019-08-22 16:48 ` [PATCH 2/2 nf-next v2] netfilter: nft_quota: add quota object update support Fernando Fernandez Mancera
2019-08-23 12:41 ` [PATCH 1/2 nf-next v2] netfilter: nf_tables: Introduce stateful object update operation Pablo Neira Ayuso
2019-08-23 12:42   ` Pablo Neira Ayuso
2019-08-23 18:05     ` Fernando Fernandez Mancera
2019-08-23 18:28       ` Fernando Fernandez Mancera
2019-08-24 16:29         ` Pablo Neira Ayuso [this message]
2019-08-26 10:16           ` Fernando Fernandez Mancera
2019-08-26 10:31             ` Pablo Neira Ayuso
2019-08-26 10:38               ` Fernando Fernandez Mancera

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=20190824162934.sdlrz56out4tzlw7@salvia \
    --to=pablo@netfilter.org \
    --cc=ffmancera@riseup.net \
    --cc=netfilter-devel@vger.kernel.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).