Re: [PATCH nf-next v3 0/5] netfilter: nf_tables: reduce set element transaction size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 17, 2024 at 12:24 PM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
>
> Cc'ing audit ML.

Thank you.

> On Wed, Oct 16, 2024 at 06:10:44PM +0200, Florian Westphal wrote:
> > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > > > This is bad, but I do not know if we can change things to make
> > > > nft_audit NOT do that.  Hence add a new workaround patch that
> > > > inflates the length based on the number of set elements in the
> > > > container structure.
> > >
> > > It actually shows the number of entries that have been updated, right?
> > >
> > > Before this series, there was a 1:1 mapping between transaction and
> > > objects so it was easier to infer it from the number of transaction
> > > objects.
> >
> > Yes, but... for element add (but not create), we used to not do anything
> > (no-op), so we did not allocate a new transaction and pretend request
> > did not exist.
>
> You refer to element updates above, those used to be elided, yes. Now
> they are shown. I think that is correct.
>
> > Now we can enter update path, so we do allocate a transaction, hence,
> > audit record changes.
> >
> > What if we add an internal special-case 'flush' op in the future?
>
> You mean, if 'flush' does not get expanded to one delete transaction
> for each element. Yes, that would require to look at ->nelems as in
> this patch.
>
> > It will break, and the workaround added in this series needs to be
> > extended.
> >
> > Same for an other change that could elide a transaction request, or,
> > add expand something to multiple ones (as flush currently does).
> >
> > Its doesn't *break* audit, but it changes the output.
>
> My understanding is that audit is exposing the entries that have been
> added/updated/deleted, which is already sparse: Note that nftables
> audit works at 'table' granurality.
>
> IIRC, one of the audit maintainers mentioned it should be possible to
> add chain and set to the audit logs in the future, such change would
> necessarily change the audit logs output.

For those of us joining the conversation late, can you provide a quick
summary of what you want to change in audit and why?

-- 
paul-moore.com





[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux