Re: [PATCH nf] netfilter: nf_tables: do not refresh timeout when resetting element

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Wed, Oct 04, 2023 at 10:07:02AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > We will soon need NFT_MSG_GETRULE_RESET_NO_TIMEOUT to undo this combo
> > command semantics, from userspace this will require some sort of 'nft
> > reset table x notimeout' syntax.
> 
> NFT_MSG_GETRULE_RESET_NO_TIMEOUT sounds super ugly :/
> 
> Do you think we can add a flags attr that describes which parts
> to reset?

Sure. This will require one attribute for each object type, also
reject it where it does not make sense.

> No flags attr would reset everything.

Refreshing timers is a bad default behaviour.

And how does this mix with the set element timeout model from
transaction? Now timers becomes a "moving target" again with this
refresh? Oh, this will drag commit_mutex to netlink dump path to avoid
that.

> Do you consider reset of timers to be something that must
> be handled via transaction infra or do you think it can
> (re)use the dump-and-reset approach?

The question why user wants to reset the timers in this path.

For counters, this is to collect stats while leaving remaining things
as is. Refreshing timers make no sense to me.

For quota, this is to fetch the consumed quota and restart it, it
might make sense to refresh the timer, but transaction sounds like a
better path for this usecase?

For limit, they do not expose internal stateful information, so this
just a reset. Timer refresh makes no sense to me here.

If this is for a dynamic set, user is refreshing/extending the
timeout, but usually it is packet path that refreshes this timeouts
via update.

This reset feature is just there to collect stateful properties and
leave things as is.