From: Andrea Mayer <andrea.mayer@uniroma2.it>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
David Ahern <dsahern@kernel.org>, Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Stefano Salsano <stefano.salsano@uniroma2.it>,
Paolo Lungaroni <paolo.lungaroni@uniroma2.it>,
Ahmed Abdelsalam <ahabdels.dev@gmail.com>,
Andrea Mayer <andrea.mayer@uniroma2.it>
Subject: Re: [net-next 1/2] seg6: add NEXT-C-SID support for SRv6 End.X behavior
Date: Fri, 4 Aug 2023 14:41:18 +0200 [thread overview]
Message-ID: <20230804144118.a52808dc5fecda09751fae9d@uniroma2.it> (raw)
In-Reply-To: <ZMtztGiOWV6bqCLg@Laptop-X1>
Hi Hangbin,
thanks for your time. Please see below.
On Thu, 3 Aug 2023 17:30:28 +0800
Hangbin Liu <liuhangbin@gmail.com> 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;
}
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
next prev parent reply other threads:[~2023-08-04 12:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 17:51 [net-next 0/2] seg6: add NEXT-C-SID support for SRv6 End.X behavior Andrea Mayer
2023-07-31 17:51 ` [net-next 1/2] " Andrea Mayer
2023-08-03 9:30 ` Hangbin Liu
2023-08-04 12:41 ` Andrea Mayer [this message]
2023-08-05 8:17 ` Hangbin Liu
2023-08-08 13:52 ` Andrea Mayer
2023-07-31 17:51 ` [net-next 2/2] selftests: seg6: add selftest for NEXT-C-SID flavor in " Andrea Mayer
2023-08-03 8:07 ` Paolo Abeni
2023-08-04 21:39 ` Paolo Lungaroni
2023-08-03 9:26 ` [net-next 0/2] seg6: add NEXT-C-SID support for " Hangbin Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230804144118.a52808dc5fecda09751fae9d@uniroma2.it \
--to=andrea.mayer@uniroma2.it \
--cc=ahabdels.dev@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paolo.lungaroni@uniroma2.it \
--cc=shuah@kernel.org \
--cc=stefano.salsano@uniroma2.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox