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] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2023 10:15:29 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jamal Hadi Salim <hadi@...atatu.com>
Cc: Jamal Hadi Salim <jhs@...atatu.com>, netdev@...r.kernel.org,
 deb.chatterjee@...el.com, tom@...anda.io, p4tc-discussions@...devconf.info,
 Mahesh.Shirshyad@....com, Vipin.Jain@....com, tomasz.osinski@...el.com,
 xiyou.wangcong@...il.com, davem@...emloft.net, edumazet@...gle.com,
 pabeni@...hat.com, khalidm@...dia.com, toke@...hat.com
Subject: Re: [p4tc-discussions] Re: [PATCH RFC v2 net-next 03/28] net/sched:
 act_api: increase TCA_ID_MAX

On Tue, 6 Jun 2023 13:04:18 -0400 Jamal Hadi Salim wrote:
> > > diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> > > index 5b66df3ec332..337411949ad0 100644
> > > --- a/include/uapi/linux/pkt_cls.h
> > > +++ b/include/uapi/linux/pkt_cls.h
> > > @@ -140,9 +140,9 @@ enum tca_id {
> > >       TCA_ID_MPLS,
> > >       TCA_ID_CT,
> > >       TCA_ID_GATE,
> > > -     TCA_ID_DYN,
> > > +     TCA_ID_DYN = 256,
> > >       /* other actions go here */
> > > -     __TCA_ID_MAX = 255
> > > +     __TCA_ID_MAX = 1023
> > >  };
> > >
> > >  #define TCA_ID_MAX __TCA_ID_MAX  
> >
> > I haven't look at any of the patches but this stands out as bad idea
> > on the surface.  
> 
> The idea is to reserve a range of the IDs for dynamic use in this case
> from 256-1023. The kernel will issue an action id from that range when
> we request it. The assumption is someone adding a "static" action ID
> will populate the above enum and is able to move the range boundaries.
> P4TC continues to work with old and new kernels and with old and new
> tc.
> Did i miss something you were alluding to?

Allocating action IDs for P4 at the same level as normal TC actions
makes the P4 stuff looks like a total parallel implementation to me.
Why is there not a TCA_ID_P4 which muxes internally?
AFAIU interpretation of action attributes depends on the ID, which
means that user space to parse the action attrs has to not only look 
at the ID but now also resolve what that ID means.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ