[PATCH v4 net-next 07/14] net: enetc: add support for "Add" and "Delete" operations to IPFT

[Wei Fang]

> > +int ntmp_ipft_add_entry(struct ntmp_user *user,
> > +			struct ipft_entry_data *entry)
> > +{
> [ ... ]
> > +	err = ntmp_alloc_data_mem(&data, (void **)&req);
> > +	if (err)
> > +		return err;
> > +
> > +	ntmp_fill_crd(&req->crd, user->tbl.ipft_ver, NTMP_QA_ENTRY_ID,
> > +		      NTMP_GEN_UA_CFGEU | NTMP_GEN_UA_STSEU);
> > +	req->ak.keye = entry->keye;
> > +	req->cfge = entry->cfge;
> 
> The request sets NTMP_GEN_UA_STSEU to indicate statistics data is present,
> but struct ipft_req_ua does not appear to contain a match_count or STSE data
> field before cfge.
> 
> Since the hardware expects STSE data before CFGE data (as seen in
> struct ipft_resp_query), will this cause the hardware to misinterpret the
> first 8 bytes of cfge as the match_count, and then read the actual filter
> configuration from out-of-bounds or uninitialized memory?

Based on NETC manual, the STSE_DATA is present only for the commands
which perform a query. So for the 'add' command, we do not need to
provide the STSE_DATA buffer. And STSE_DATA is the statistics of the
entry, which is stored in the internal buffer of IPF table. Performing
NTMP_GEN_UA_STSEU is to reset the statistic counter when adding
an entry.

[...]

> > +struct ipft_pld_byte {
> > +	u8 data;
> > +	u8 mask;
> > +};
> > +
> > +struct ipft_keye_data {
> > +	__le16 precedence;
> > +	__le16 resv0[3];
> > +	__le16 frm_attr_flags;
> > +#define IPFT_FAF_OVLAN		BIT(2)
> > +#define IPFT_FAF_IVLAN		BIT(3)
> > +#define IPFT_FAF_IP_HDR		BIT(7)
> > +#define IPFT_FAF_IP_VER6	BIT(8)
> > +#define IPFT_FAF_L4_CODE	GENMASK(11, 10)
> > +#define  IPFT_FAF_TCP_HDR	1
> > +#define  IPFT_FAF_UDP_HDR	2
> > +#define  IPFT_FAF_SCTP_HDR	3
> > +#define IPFT_FAF_WOL_MAGIC	BIT(12)
> > +	__le16 frm_attr_flags_mask;
> > +	__le16 dscp;
> > +#define IPFT_DSCP		GENMASK(5, 0)
> > +#define IPFT_DSCP_MASK		GENMASK(11, 0)
> 
> Does IPFT_DSCP_MASK completely overlap with IPFT_DSCP?
> 
> If it is defined as GENMASK(11, 0) instead of GENMASK(11, 6), using
> FIELD_PREP with this mask will not shift the value into the upper bits,
> which might overwrite the actual DSCP value in bits 0-5.

Thanks, this is a bug, I will fix it.