From: Andrea Mayer <andrea.mayer@uniroma2.it>
To: David Ahern <dsahern@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
David Ahern <dsahern@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Colin Ian King <colin.king@canonical.com>,
Stefano Salsano <stefano.salsano@uniroma2.it>,
Paolo Lungaroni <paolo.lungaroni@cnit.it>,
Ahmed Abdelsalam <ahabdels.dev@gmail.com>,
Andrea Mayer <andrea.mayer@uniroma2.it>
Subject: Re: [PATCH net-next] seg6: fool-proof the processing of SRv6 behavior attributes
Date: Thu, 4 Feb 2021 03:27:27 +0100 [thread overview]
Message-ID: <20210204032727.ffd2c1ae3410147ba7598d78@uniroma2.it> (raw)
In-Reply-To: <6fe3beb2-4306-11cd-83ce-66072db81346@gmail.com>
Hi David,
thanks for your time.
On Wed, 3 Feb 2021 08:59:40 -0700
David Ahern <dsahern@gmail.com> wrote:
> On 2/2/21 11:56 AM, Andrea Mayer wrote:
> > diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> > index b07f7c1c82a4..7cc50d506902 100644
> > --- a/net/ipv6/seg6_local.c
> > +++ b/net/ipv6/seg6_local.c
> > @@ -31,6 +31,9 @@
> > #include <linux/etherdevice.h>
> > #include <linux/bpf.h>
> >
> > +#define SEG6_F_ATTR(i) BIT(i)
> > +#define SEG6_LOCAL_MAX_SUPP 32
> > +
>
> SEG6_LOCAL_MAX_SUPP should not be needed; it can be derived from the type:
>
Yes, we can avoid the SEG6_LOCAL_MAX_SUPP. Using the BITS_PER_TYPE macro seems
better to me and it avoids nailing the value 32 as the limit. At compile time,
the kernel build will fail if the total number of SRv6 attributes will exceed
the number of bits available in the unsigned long bitmap (whatever is the
reference architecture). Therefore, I'm going to follow your suggestion!
> BUILD_BUG_ON(BITS_PER_TYPE(unsigned long) > SEG6_LOCAL_MAX)
>
I think there is an issue here because BITS_PER_TYPE(unsigned long) is greater
than the SEG6_LOCAL_MAX (currently = 9).
I think it should be like this:
BUILD_BUG_ON(SEG6_LOCAL_MAX + 1 > BITS_PER_TYPE(unsigned long))
I will send a v2 with the changes discussed so far.
Thank you,
Andrea
next prev parent reply other threads:[~2021-02-04 2:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 18:56 [PATCH net-next] seg6: fool-proof the processing of SRv6 behavior attributes Andrea Mayer
2021-02-03 15:59 ` David Ahern
2021-02-04 2:27 ` Andrea Mayer [this message]
2021-02-04 3:00 ` David Ahern
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=20210204032727.ffd2c1ae3410147ba7598d78@uniroma2.it \
--to=andrea.mayer@uniroma2.it \
--cc=ahabdels.dev@gmail.com \
--cc=colin.king@canonical.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=dsahern@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paolo.lungaroni@cnit.it \
--cc=stefano.salsano@uniroma2.it \
--cc=yoshfuji@linux-ipv6.org \
/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;
as well as URLs for NNTP newsgroup(s).