From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
To: Brian Haley <brian.haley@hp.com>
Cc: hannes@stressinduktion.org, netdev@vger.kernel.org,
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Subject: Re: [PATCH net-next 2/3] ipv6: use newly introduced __ipv6_addr_needs_scope_id and ipv6_iface_scope_id
Date: Thu, 14 Feb 2013 01:47:47 +0900 [thread overview]
Message-ID: <511BC3B3.3070405@linux-ipv6.org> (raw)
In-Reply-To: <511AFF9A.8040506@hp.com>
Brian Haley wrote:
> On 02/12/2013 07:13 PM, Hannes Frederic Sowa wrote:
>>> --- a/net/ipv6/af_inet6.c
>>> +++ b/net/ipv6/af_inet6.c
>>> @@ -323,7 +323,7 @@ int inet6_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
>>> struct net_device *dev = NULL;
>>>
>>> rcu_read_lock();
>>> - if (addr_type & IPV6_ADDR_LINKLOCAL) {
>>> + if (__ipv6_addr_needs_scope_id(addr_type)) {
>>> if (addr_len >= sizeof(struct sockaddr_in6) &&
>>> addr->sin6_scope_id) {
>>> /* Override any existing binding, if another one
>>
>> By trying to setup the multicast interface scoped routes by default I
>> just found a bug in this patch essentially breaking ipv6 multicast. I
>> overlooked that ipv6_addr_type strips off the scopes, thus my check if
>> a multicast address needs a scope_id always returns true. I'll check
>> if I can convert the ipv6_addr_type calls to __ipv6_addr_type and will
>> reroll the patch. Sorry, my tests were too focused on interface/local
>> multicast. :(
>
> I'd always thought of adding helper inlines like these in net/ipv6.h:
>
> static inline bool ipv6_addr_linklocal(const struct in6_addr *a)
> {
> return ((a->s6_addr32[0] & htonl(0xFFC00000)) == htonl(0xFE800000));
> }
>
> static inline bool ipv6_addr_mc_linklocal(const struct in6_addr *a)
> {
> return (((a->s6_addr32[0] & htonl(0xFF000000)) == htonl(0xFF000000)) &&
> ((a->s6_addr32[1] & 0x0F) == IPV6_ADDR_SCOPE_LINKLOCAL));
> }
>
> Maybe something like that would help here?
If you have several address checks around, please use ipv6_addr_type()
(or __ipv6_addr_type()). Above "direct" checks should be used only for
single-shot test. But well, I have to agree that ipv6_addr_type and
friends is becoming complex. In mid-term, I would like to take look
at it. I might think of having addr_type for src/dst in skb->cb
after all.
--yoshfuji
next prev parent reply other threads:[~2013-02-13 16:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 22:16 [PATCH net-next 2/3] ipv6: use newly introduced __ipv6_addr_needs_scope_id and ipv6_iface_scope_id Hannes Frederic Sowa
2013-02-13 0:13 ` Hannes Frederic Sowa
2013-02-13 2:51 ` Brian Haley
2013-02-13 10:33 ` Hannes Frederic Sowa
2013-02-13 16:47 ` YOSHIFUJI Hideaki [this message]
2013-02-13 17:21 ` Hannes Frederic Sowa
2013-02-14 4:25 ` Hannes Frederic Sowa
2013-02-14 15:25 ` Brian Haley
2013-02-14 18:53 ` Hannes Frederic Sowa
2013-02-14 19:31 ` Brian Haley
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=511BC3B3.3070405@linux-ipv6.org \
--to=yoshfuji@linux-ipv6.org \
--cc=brian.haley@hp.com \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.