[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1484244839.3869.0@smtp.office365.com>
Date: Thu, 12 Jan 2017 13:13:59 -0500
From: Josef Bacik <jbacik@...com>
To: Craig Gallek <kraigatgoog@...il.com>
CC: David Miller <davem@...emloft.net>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Eric Dumazet <eric.dumazet@...il.com>,
"Tom Herbert" <tom@...bertland.com>,
netdev <netdev@...r.kernel.org>, <kernel-team@...com>
Subject: Re: [PATCH 1/6 net-next] inet: collapse ipv4/v6 rcv_saddr_equal
functions into one
On Thu, Jan 12, 2017 at 12:41 PM, Craig Gallek <kraigatgoog@...il.com>
wrote:
> On Wed, Jan 11, 2017 at 3:19 PM, Josef Bacik <jbacik@...com> wrote:
>> +int inet_rcv_saddr_equal(const struct sock *sk, const struct sock
>> *sk2,
>> + bool match_wildcard)
>> +{
>> +#if IS_ENABLED(CONFIG_IPV6)
>> + if (sk->sk_family == AF_INET6)
> Still wrapping my head around this, so take it with a grain of salt,
> but it's not obvious to me that sk and sk2 are guaranteed to have the
> same family here (or if it even matters). Especially in the context
> of the next patch which removes the bind_conflict callback... Does
> this need to be an OR check for the family of either socket? Or is it
> safe as-is because the first socket passed to this function is always
> the existing one and the second one is the possible conflict socket?
It's safe as is, all we care is that sk1 is the INET6 socket. In the
compare function we use inet6_rcv_saddr(sk2) which will return NULL if
it isn't INET6 and then the function handles that case appropriately.
This stuff is subtle so it's easy to get confused, I always made sure
to run it on our production boxes to make sure I didn't break something
;). Thanks,
Josef
Powered by blists - more mailing lists