Re: [net-next 1/2] seg6: add NEXT-C-SID support for SRv6 End.X behavior

From: Hangbin Liu
Date: Sat Aug 05 2023 - 04:17:17 EST


On Fri, Aug 04, 2023 at 02:41:18PM +0200, Andrea Mayer wrote:
> Hi Hangbin,
> thanks for your time. Please see below.
>
> On Thu, 3 Aug 2023 17:30:28 +0800
> Hangbin Liu <liuhangbin@xxxxxxxxx> wrote:
>
> > On Mon, Jul 31, 2023 at 07:51:16PM +0200, Andrea Mayer wrote:
> > > +/* Processing of SRv6 End, End.X, and End.T behaviors can be extended through
> > > + * the flavors framework. These behaviors must report the subset of (flavor)
> > > + * operations they currently implement. In this way, if a user specifies a
> > > + * flavor combination that is not supported by a given End* behavior, the
> > > + * kernel refuses to instantiate the tunnel reporting the error.
> > > + */
> > > +static int seg6_flv_supp_ops_by_action(int action, __u32 *fops)
> > > +{
> > > + switch (action) {
> > > + case SEG6_LOCAL_ACTION_END:
> > > + *fops = SEG6_LOCAL_END_FLV_SUPP_OPS;
> > > + break;
> > > + case SEG6_LOCAL_ACTION_END_X:
> > > + *fops = SEG6_LOCAL_END_X_FLV_SUPP_OPS;
> > > + break;
> > > + default:
> > > + return -EOPNOTSUPP;
> > > + }
> > > +
> > > + return 0;
> > > }
> > >
> >
> > ...
> >
> > > @@ -2070,7 +2131,8 @@ static int parse_nla_flavors(struct nlattr **attrs, struct seg6_local_lwt *slwt,
> > > {
> > > struct seg6_flavors_info *finfo = &slwt->flv_info;
> > > struct nlattr *tb[SEG6_LOCAL_FLV_MAX + 1];
> > > - unsigned long fops;
> > > + int action = slwt->action;
> > > + __u32 fops, supp_fops = 0;
> > > int rc;
> > >
> > > rc = nla_parse_nested_deprecated(tb, SEG6_LOCAL_FLV_MAX,
> > > @@ -2086,7 +2148,8 @@ static int parse_nla_flavors(struct nlattr **attrs, struct seg6_local_lwt *slwt,
> > > return -EINVAL;
> > >
> > > fops = nla_get_u32(tb[SEG6_LOCAL_FLV_OPERATION]);
> > > - if (fops & ~SEG6_LOCAL_FLV_SUPP_OPS) {
> > > + rc = seg6_flv_supp_ops_by_action(action, &supp_fops);
> > > + if (rc < 0 || !supp_fops || (fops & ~supp_fops)) {
> >
> > if rc == 0, the supp_fops won't be 0.
> >
>
> Yes, you're right.
>
> In this patch, supp_fops is always set properly when rc == 0.
> Since seg6_flv_supp_ops_by_action() should be extended in the event that other
> behaviors receive flavors support, I added this check in case the "supp_fops"
> field was set incorrectly or not set at all.
> Note that supp_fops == 0 must be considered an inadmissible value.
>
>
> So, I think we have two possibilities:
> i) remove this "defensive" check, assuming that supp_fops will always be set
> correctly by seg6_flv_supp_ops_by_action() (when rc == 0, like in this
> patch);
> ii) improve the check by explicitly indicating with a pr_warn_once, for
> example, the condition that is occurring is unexpected.
>
> for (ii), something like this:
>
> parse_nla_flavors(...)
> {
> [...]
> supp_fops = 0;
> [...]
>
> rc = seg6_flv_supp_ops_by_action(action, &supp_fops);
> if (!rc && !supp_fops) {
> /* supported flavors mask cannot be zero as it is considered to
> * be invalid.
> */
> pr_warn_once("seg6local: invalid Flavor operation(s)");
> return -EINVAL;
> }

Do you mean there is a possibility *in future* that the supp_fops could be 0
with rc == 0? If yes, this check would make sense(although we can add this
check when it's true). If not. I don't see a need to have this check.

And some static analysis tool would report warn for this code.

Thanks
Hangbin
>
> fops = nla_get_u32(tb[SEG6_LOCAL_FLV_OPERATION]);
> if (rc < 0 || (fops & ~supp_fops)) {
> NL_SET_ERR_MSG(extack, "Unsupported Flavor operation(s)");
> return -EOPNOTSUPP;
> }
>
> finfo->flv_ops = fops;
>
> [...]
> }
>
> parse_nla_flavors() is called in the control path so another check would not
> hit performance. I am more inclined to consider solution (ii).
>
> What do you think?
>
> > Thanks
> > Hangbin
>
> Ciao,
> Andrea