On Tue, Mar 12, 2024 at 01:27:58PM +0100, Florian Westphal wrote:
> Quan Tian <tianquan23@xxxxxxxxx> wrote:
> > The NFTA_TABLE_USERDATA attribute was ignored on updates. The patch adds
> > handling for it to support table comment updates.
>
> One generic API question below. Pablo, please look at this too.
>
> > case NFT_MSG_NEWTABLE:
> > if (nft_trans_table_update(trans)) {
> > - if (!(trans->ctx.table->flags & __NFT_TABLE_F_UPDATE)) {
> > - nft_trans_destroy(trans);
> > - break;
> > + if (trans->ctx.table->flags & __NFT_TABLE_F_UPDATE) {
> > + if (trans->ctx.table->flags & NFT_TABLE_F_DORMANT)
> > + nf_tables_table_disable(net, trans->ctx.table);
> > + trans->ctx.table->flags &= ~__NFT_TABLE_F_UPDATE;
> > }
> > - if (trans->ctx.table->flags & NFT_TABLE_F_DORMANT)
> > - nf_tables_table_disable(net, trans->ctx.table);
> > -
> > - trans->ctx.table->flags &= ~__NFT_TABLE_F_UPDATE;
> > + swap(trans->ctx.table->udata, nft_trans_table_udata(trans));
> > + nf_tables_table_notify(&trans->ctx, NFT_MSG_NEWTABLE
>
> AFAICS this means that if the table as udata attached, and userspace
> makes an update request without a UDATA netlink attribute, we will
> delete the existing udata.
>
> Is that right?
>
> My question is, should we instead leave the existing udata as-is and not
> support removal, only replace?
I would leave it in place too if no _USERDATA is specified.
One more question is if the memcmp() with old and new udata makes
sense considering two consecutive requests for _USERDATA update in one
batch.
