Re: [nft PATCH] table: Embed creating nft version into userdata

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

On Thu, Aug 28, 2025 at 03:53:14PM +0200, Phil Sutter wrote:
> On Thu, Aug 28, 2025 at 02:53:29PM +0200, Pablo Neira Ayuso wrote:
> > Hi Phil,
> > 
> > I know this is applied, but one late question.
> > 
> > On Wed, Aug 13, 2025 at 07:07:19PM +0200, Phil Sutter wrote:
> > > @@ -806,6 +815,29 @@ static int table_parse_udata_cb(const struct nftnl_udata *attr, void *data)
> > >  	return 0;
> > >  }
> > >  
> > > +static int version_cmp(const struct nftnl_udata **ud)
> > > +{
> > > +	const char *udbuf;
> > > +	size_t i;
> > > +
> > > +	/* netlink attribute lengths checked by table_parse_udata_cb() */
> > > +	if (ud[NFTNL_UDATA_TABLE_NFTVER]) {
> > > +		udbuf = nftnl_udata_get(ud[NFTNL_UDATA_TABLE_NFTVER]);
> > > +		for (i = 0; i < sizeof(nftversion); i++) {
> > > +			if (nftversion[i] != udbuf[i])
> > > +				return nftversion[i] - udbuf[i];
> > > +		}
> > > +	}
> > > +	if (ud[NFTNL_UDATA_TABLE_NFTBLD]) {
> > > +		udbuf = nftnl_udata_get(ud[NFTNL_UDATA_TABLE_NFTBLD]);
> > > +		for (i = 0; i < sizeof(nftbuildstamp); i++) {
> > > +			if (nftbuildstamp[i] != udbuf[i])
> > > +				return nftbuildstamp[i] - udbuf[i];
> > > +		}
> > > +	}
> > 
> > One situation I was considering:
> > 
> > 1.0.6.y (build today) in the host
> > 1.1.5 (build n days ago) in the container
> > 
> > This will display the warning.
> > 
> > I suggested to use build time only when version is the same?
> > 
> > If the scenario is nftables in the host injects tables into container,
> > then host binary will likely be updated more often.
> > 
> > IIUC, the build time here will actually determine when the warning is
> > emitted, regardless the version.
> 
> It should not:
> 
> Here's version_cmp() pseudo-code:
> 
> | for attr in NFTNL_UDATA_TABLE_NFTVER, NFTNL_UDATA_TABLE_NFTBLD:
> | 	for idx in len(attr):
> | 		if local_data[idx] != attr[idx]:
> | 			return local_data[idx] - attr[idx];
> 
> This algorithm considers following bytes only if all previous ones were
> identical. Precedence is from highest order version bytes to lowest
> order build bytes (data is therefore stored in Big Endian).
> 
> So your version 1.1.5 will always be "newer" than 1.0.6.y, no matter the
> build date, due to minor version 1 > 0.

Ah, I misread this smart function, thanks for clarifying.