linux-kernel - Re: [PATCH net-next 1/2] net: sparx5: flower: cleanup sparx5_tc_flower_handler_control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240423191516.o6ssgqhrsk7hizdk@DEN-DL-M70577>
Date: Tue, 23 Apr 2024 19:15:16 +0000
From: Daniel Machon <daniel.machon@...rochip.com>
To: Asbjørn Sloth Tønnesen <ast@...erby.net>
CC: <netdev@...r.kernel.org>, Steen Hegelund <Steen.Hegelund@...rochip.com>,
	Lars Povlsen <lars.povlsen@...rochip.com>, <UNGLinuxDriver@...rochip.com>,
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	<linux-kernel@...r.kernel.org>, Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [PATCH net-next 1/2] net: sparx5: flower: cleanup
 sparx5_tc_flower_handler_control_usage()

> > > -       if (mt.mask->flags) {
> > > +       if (mt.mask->flags & (FLOW_DIS_IS_FRAGMENT | FLOW_DIS_FIRST_FRAG)) {
> > 
> > Since these flags are used here and in the next patch, maybe assign them
> > to a variable:
> > 
> > u32 supp_flags = FLOW_DIS_IS_FRAGMENT | FLOW_DIS_FIRST_FRAG
> > 
> > And update the use throughout.
> 
> In an earlier state this patch had a #define SPARX5_FLOWER_SUPPORTED_CTLFLAGS,
> in the same style as nfp in drivers/net/ethernet/netronome/nfp/flower/offload.c
> 
> Right now, this driver supports all currently defined flags (which are used with mask),
> so the point of using flow_rule_is_supp_control_flags() to this dirver, is to
> make it possible to introduce new flags in the future, without having to update
> all drivers to explicitly not support a new flag.
> 
> My problem with using supp_flags in both places is: What happens when support
> for a new flag is introduced?
> 
> u32 supp_flags = FLOW_DIS_IS_FRAGMENT | FLOW_DIS_FIRST_FRAG | FLOW_DIS_NEW_FLAG;
> 
> if (mt.mask->flags & (FLOW_DIS_IS_FRAGMENT | FLOW_DIS_FIRST_FRAG))
>         /* handle fragment flags through lookup table */
> 
> if (mt.mask->flags & FLOW_DIS_NEW_FLAG)
>         /* do something */
> 
> if (!flow_rule_is_supp_control_flags(supp_flags, mt.mask->flags, extack))
>         return -EOPNOTSUPP;
> 
> The fragment lookup table code currently requires the above guarding,
> as [0][0] in the lookup table is FRAG_INVAL, and not FRAG_SHRUG.
> 
> What do you think?

Yes - lets only check for fragment flags when doing the lookup. I am
fine with your original impl.

If you can fix the remaining issue, I will take the patches for a test
spin tomorrow.

Thanks!

> 
> --
> Best regards
> Asbjørn Sloth Tønnesen
> Network Engineer
> Fiberby - AS42541