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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 9 Mar 2020 14:36:30 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, <netdev@...r.kernel.org>,
        <davem@...emloft.net>, <saeedm@...lanox.com>, <leon@...nel.org>,
        <michael.chan@...adcom.com>, <vishal@...lsio.com>,
        <jeffrey.t.kirsher@...el.com>, <idosch@...lanox.com>,
        <aelior@...vell.com>, <peppe.cavallaro@...com>,
        <alexandre.torgue@...com>, <jhs@...atatu.com>,
        <xiyou.wangcong@...il.com>, <pablo@...filter.org>,
        <mlxsw@...lanox.com>
Subject: Re: [patch net-next v4 01/10] flow_offload: Introduce offload of HW
 stats type

On Mon, 9 Mar 2020 16:52:16 +0000 Edward Cree wrote:
> On 07/03/2020 11:40, Jiri Pirko wrote:
> > From: Jiri Pirko <jiri@...lanox.com>
> >
> > Initially, pass "ANY" (struct is zeroed) to the drivers as that is the
> > current implicit value coming down to flow_offload. Add a bool
> > indicating that entries have mixed HW stats type.
> >
> > Signed-off-by: Jiri Pirko <jiri@...lanox.com>
> > ---
> > v3->v4:
> > - fixed member alignment
> > v2->v3:
> > - moved to bitfield
> > - removed "mixed" bool
> > v1->v2:
> > - moved to actions
> > - add mixed bool
> > ---
> >  include/net/flow_offload.h | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
> > index cd3510ac66b0..93d17f37e980 100644
> > --- a/include/net/flow_offload.h
> > +++ b/include/net/flow_offload.h
> > @@ -154,6 +154,8 @@ enum flow_action_mangle_base {
> >  	FLOW_ACT_MANGLE_HDR_TYPE_UDP,
> >  };
> >  
> > +#define FLOW_ACTION_HW_STATS_TYPE_ANY 0  
> I'm not quite sure why switching to a bit fieldapproach means these
>  haveto become #defines rather than enums...

Perhaps having enum defining the values could be argued...

> > +
> >  typedef void (*action_destr)(void *priv);
> >  
> >  struct flow_action_cookie {
> > @@ -168,6 +170,7 @@ void flow_action_cookie_destroy(struct flow_action_cookie *cookie);
> >  
> >  struct flow_action_entry {
> >  	enum flow_action_id		id;
> > +	u8				hw_stats_type;  
> ... causing this to become a u8with nothing obviously preventing
>  a HW_STATS_TYPE bigger than 255 getting defined.
> An enum type seems safer.

...but using the type for fields which are very likely to contain
values from outside of the enumeration seems confusing, IMHO.

Driver author can understandably try to simply handle all the values 
in a switch statement and be unpleasantly surprised.

Powered by blists - more mailing lists