Netdev Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH net] ipv6: fix neighbour resolution with raw socket
@ 2019-06-20 12:34 Nicolas Dichtel
  2019-06-20 15:12 ` David Ahern
                   ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Nicolas Dichtel @ 2019-06-20 12:34 UTC (permalink / raw)
  To: davem; +Cc: netdev, Nicolas Dichtel

The scenario is the following: the user uses a raw socket to send an ipv6
packet, destinated to a not-connected network, and specify a connected nh.
Here is the corresponding python script to reproduce this scenario:

 import socket
 IPPROTO_RAW = 255
 send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
 # scapy
 # p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
 # str(p)
 req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
 send_s.sendto(req, ('fd00:175::2', 0, 0, 0))

fd00:175::/64 is a connected route and fd00:200::fa is not a connected
host.

With this scenario, the kernel starts by sending a NS to resolve
fd00:175::2. When it receives the NA, it flushes its queue and try to send
the initial packet. But instead of sending it, it sends another NS to
resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
the user sends again the packet, it now uses the right nh (fd00:175::2).

The problem is that ip6_dst_lookup_neigh() uses the rt6i_gateway, which is
:: because the associated route is a connected route, thus it uses the dst
addr of the packet. Let's use rt6_nexthop() to choose the right nh.

Note that rt and in6addr_any are const in ip6_dst_lookup_neigh(), thus
let's constify rt6_nexthop() to avoid ugly cast.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 include/net/ip6_route.h | 4 ++--
 net/ipv6/ip6_output.c   | 2 +-
 net/ipv6/route.c        | 3 ++-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 4790beaa86e0..ee7405e759ba 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -262,8 +262,8 @@ static inline bool ip6_sk_ignore_df(const struct sock *sk)
 	       inet6_sk(sk)->pmtudisc == IPV6_PMTUDISC_OMIT;
 }
 
-static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt,
-					   struct in6_addr *daddr)
+static inline const struct in6_addr *rt6_nexthop(const struct rt6_info *rt,
+						 const struct in6_addr *daddr)
 {
 	if (rt->rt6i_flags & RTF_GATEWAY)
 		return &rt->rt6i_gateway;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 834475717110..21efcd02f337 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -59,8 +59,8 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
 {
 	struct dst_entry *dst = skb_dst(skb);
 	struct net_device *dev = dst->dev;
+	const struct in6_addr *nexthop;
 	struct neighbour *neigh;
-	struct in6_addr *nexthop;
 	int ret;
 
 	if (ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr)) {
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 11ad62effd56..b6449bc03f11 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -218,7 +218,8 @@ static struct neighbour *ip6_dst_neigh_lookup(const struct dst_entry *dst,
 {
 	const struct rt6_info *rt = container_of(dst, struct rt6_info, dst);
 
-	return ip6_neigh_lookup(&rt->rt6i_gateway, dst->dev, skb, daddr);
+	return ip6_neigh_lookup(rt6_nexthop(rt, &in6addr_any),
+				dst->dev, skb, daddr);
 }
 
 static void ip6_confirm_neigh(const struct dst_entry *dst, const void *daddr)
-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
  2019-06-20 12:34 [PATCH net] ipv6: fix neighbour resolution with raw socket Nicolas Dichtel
@ 2019-06-20 15:12 ` David Ahern
  2019-06-20 15:42   ` Nicolas Dichtel
  2019-06-21 18:48 ` kbuild test robot
  2019-06-23  0:07 ` David Miller
  2 siblings, 1 reply; 20+ messages in thread
From: David Ahern @ 2019-06-20 15:12 UTC (permalink / raw)
  To: Nicolas Dichtel, davem; +Cc: netdev

On 6/20/19 6:34 AM, Nicolas Dichtel wrote:
> The scenario is the following: the user uses a raw socket to send an ipv6
> packet, destinated to a not-connected network, and specify a connected nh.
> Here is the corresponding python script to reproduce this scenario:
> 
>  import socket
>  IPPROTO_RAW = 255
>  send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
>  # scapy
>  # p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
>  # str(p)
>  req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
>  send_s.sendto(req, ('fd00:175::2', 0, 0, 0))
> 
> fd00:175::/64 is a connected route and fd00:200::fa is not a connected
> host.
> 
> With this scenario, the kernel starts by sending a NS to resolve
> fd00:175::2. When it receives the NA, it flushes its queue and try to send
> the initial packet. But instead of sending it, it sends another NS to
> resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
> the user sends again the packet, it now uses the right nh (fd00:175::2).
> 

what's the local address and route setup? You reference fd00:100::1 and
fd00:200::fa with connected route fd00:175::/64.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
  2019-06-20 15:12 ` David Ahern
@ 2019-06-20 15:42   ` Nicolas Dichtel
  2019-06-20 16:36     ` David Ahern
  0 siblings, 1 reply; 20+ messages in thread
From: Nicolas Dichtel @ 2019-06-20 15:42 UTC (permalink / raw)
  To: David Ahern, davem; +Cc: netdev

Le 20/06/2019 à 17:12, David Ahern a écrit :
> On 6/20/19 6:34 AM, Nicolas Dichtel wrote:
>> The scenario is the following: the user uses a raw socket to send an ipv6
>> packet, destinated to a not-connected network, and specify a connected nh.
>> Here is the corresponding python script to reproduce this scenario:
>>
>>  import socket
>>  IPPROTO_RAW = 255
>>  send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
>>  # scapy
>>  # p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
>>  # str(p)
>>  req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
>>  send_s.sendto(req, ('fd00:175::2', 0, 0, 0))
>>
>> fd00:175::/64 is a connected route and fd00:200::fa is not a connected
>> host.
>>
>> With this scenario, the kernel starts by sending a NS to resolve
>> fd00:175::2. When it receives the NA, it flushes its queue and try to send
>> the initial packet. But instead of sending it, it sends another NS to
>> resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
>> the user sends again the packet, it now uses the right nh (fd00:175::2).
>>
> 
> what's the local address and route setup? You reference fd00:100::1 and
> fd00:200::fa with connected route fd00:175::/64.
> 

The test in done on the dut:

    +-----+             +------+             +------+             +-----+
    | tnl |             | dut  |.1         .2|router|             | tnr |
    |     |             |     2+-------------+2     |             |     |
    |     |.1         .2|      |fd00:125::/64|      |.2         .1|     |
    |    1+-------------+1     |             |     1+-------------+1    |
    |     |fd00:100::/64|      |             |      |fd00:200::/64|     |
    |     |             |      |.1         .2|      |             |     |
    |     |             |     3+-------------+3     |             |     |
    |     |             |      |fd00:175::/64|      |             |     |
    +-----+             +------+             +------+             +-----+

On dut:
ip address add fd00:100::2/64 dev ntfp1
ip address add fd00:125::1/64 dev ntfp2
ip address add fd00:175::1/64 dev ntfp3
ip route add fd00:200::/64 via fd00:125::2
ip route add fd00:200::/120 nexthop via fd00:125::2 nexthop via fd00:175::2

Note that fd00:200::fa is not reachable but we expect to see the packet on the
host 'router'.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
  2019-06-20 15:42   ` Nicolas Dichtel
@ 2019-06-20 16:36     ` David Ahern
  2019-06-20 16:47       ` David Ahern
  2019-06-21  8:09       ` Nicolas Dichtel
  0 siblings, 2 replies; 20+ messages in thread
From: David Ahern @ 2019-06-20 16:36 UTC (permalink / raw)
  To: nicolas.dichtel, davem; +Cc: netdev

On 6/20/19 9:42 AM, Nicolas Dichtel wrote:
> Le 20/06/2019 à 17:12, David Ahern a écrit :
>> On 6/20/19 6:34 AM, Nicolas Dichtel wrote:
>>> The scenario is the following: the user uses a raw socket to send an ipv6
>>> packet, destinated to a not-connected network, and specify a connected nh.
>>> Here is the corresponding python script to reproduce this scenario:
>>>
>>>  import socket
>>>  IPPROTO_RAW = 255
>>>  send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
>>>  # scapy
>>>  # p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
>>>  # str(p)
>>>  req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
>>>  send_s.sendto(req, ('fd00:175::2', 0, 0, 0))
>>>
>>> fd00:175::/64 is a connected route and fd00:200::fa is not a connected
>>> host.
>>>
>>> With this scenario, the kernel starts by sending a NS to resolve
>>> fd00:175::2. When it receives the NA, it flushes its queue and try to send
>>> the initial packet. But instead of sending it, it sends another NS to
>>> resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
>>> the user sends again the packet, it now uses the right nh (fd00:175::2).
>>>
>>
>> what's the local address and route setup? You reference fd00:100::1 and
>> fd00:200::fa with connected route fd00:175::/64.
>>
> 
> The test in done on the dut:
> 
>     +-----+             +------+             +------+             +-----+
>     | tnl |             | dut  |.1         .2|router|             | tnr |
>     |     |             |     2+-------------+2     |             |     |
>     |     |.1         .2|      |fd00:125::/64|      |.2         .1|     |
>     |    1+-------------+1     |             |     1+-------------+1    |
>     |     |fd00:100::/64|      |             |      |fd00:200::/64|     |
>     |     |             |      |.1         .2|      |             |     |
>     |     |             |     3+-------------+3     |             |     |
>     |     |             |      |fd00:175::/64|      |             |     |
>     +-----+             +------+             +------+             +-----+
> 
> On dut:
> ip address add fd00:100::2/64 dev ntfp1
> ip address add fd00:125::1/64 dev ntfp2
> ip address add fd00:175::1/64 dev ntfp3
> ip route add fd00:200::/64 via fd00:125::2
> ip route add fd00:200::/120 nexthop via fd00:125::2 nexthop via fd00:175::2
> 
> Note that fd00:200::fa is not reachable but we expect to see the packet on the
> host 'router'.
> 

gotcha. Thanks for the diagram.

Reviewed-by: David Ahern <dsahern@gmail.com>

You don't have a fixes tag, but this should go to stable releases.

Also, this does not fix the forwarding case. For the forwarding case I
still see it trying to resolve fd00:200::fa from dut.

Namespace version of the above setup:

create_ns() {
        local ns=$1
        ip netns add ${ns}
        ip -netns ${ns} link set lo up
        ip netns exec ${ns} sysctl -qw net.ipv4.ip_forward=1
        ip netns exec ${ns} sysctl -qw net.ipv6.conf.all.keep_addr_on_down=1
        ip netns exec ${ns} sysctl -qw net.ipv6.conf.all.forwarding=1
        ip netns exec ${ns} sysctl -qw net.ipv6.conf.default.forwarding=1
}

create_ns tnl
create_ns dut
create_ns router
create_ns tnr

ip -netns tnl li add eth1 type veth peer name eth1d
ip -netns tnl li set eth1d netns dut name eth1
ip -netns tnl li set eth1 up
ip -netns tnl addr add fd00:100::1/64 dev eth1
ip -netns tnl -6 ro add default via fd00:100::2

ip -netns dut li set eth1 up
ip -netns dut addr add fd00:100::2/64 dev eth1

ip -netns dut li add eth2 type veth peer name eth2r
ip -netns dut li set eth2r netns router name eth2
ip -netns dut li set eth2 up
ip -netns dut addr add dev eth2 fd00:125::1/64
ip -netns router  li set eth2 up
ip -netns router addr add dev eth2 fd00:125::2/64

ip -netns dut li add eth3 type veth peer name eth3r
ip -netns dut li set eth3r netns router name eth3
ip -netns dut li set eth3 up
ip -netns dut addr add dev eth3 fd00:175::1/64
ip -netns router li set eth3 up
ip -netns router addr add dev eth3 fd00:175::2/64

ip -netns router li add eth1 type veth peer name eth1t
ip -netns router li set eth1t netns tnr name eth1
ip -netns router li set eth1 up
ip -netns router addr add dev eth1 fd00:200::2/64
ip -netns tnr li set eth1 up
ip -netns tnr addr add dev eth1 fd00:200::1/64

ip -netns dut route add fd00:200::/64 via fd00:125::2
ip -netns dut route add fd00:200::/120 nexthop via fd00:125::2 nexthop
via fd00:175::2

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
  2019-06-20 16:36     ` David Ahern
@ 2019-06-20 16:47       ` David Ahern
  2019-06-21  8:09       ` Nicolas Dichtel
  1 sibling, 0 replies; 20+ messages in thread
From: David Ahern @ 2019-06-20 16:47 UTC (permalink / raw)
  To: nicolas.dichtel, davem; +Cc: netdev

On 6/20/19 10:36 AM, David Ahern wrote:
> 
> Also, this does not fix the forwarding case. For the forwarding case I
> still see it trying to resolve fd00:200::fa from dut.

nevermind. I used the wrong address for the forwarding case.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
  2019-06-20 16:36     ` David Ahern
  2019-06-20 16:47       ` David Ahern
@ 2019-06-21  8:09       ` Nicolas Dichtel
  1 sibling, 0 replies; 20+ messages in thread
From: Nicolas Dichtel @ 2019-06-21  8:09 UTC (permalink / raw)
  To: David Ahern, davem; +Cc: netdev

Le 20/06/2019 à 18:36, David Ahern a écrit :
[snip]
> You don't have a fixes tag, but this should go to stable releases.
Yeah, I was not able to point a specific commit. The bug is reproducible with a
4.4 from ubuntu-16.04, with a 3.10 from redhat-7 but not with a vanilla 3.10.20.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
  2019-06-20 12:34 [PATCH net] ipv6: fix neighbour resolution with raw socket Nicolas Dichtel
  2019-06-20 15:12 ` David Ahern
@ 2019-06-21 18:48 ` kbuild test robot
  2019-06-23  0:07 ` David Miller
  2 siblings, 0 replies; 20+ messages in thread
From: kbuild test robot @ 2019-06-21 18:48 UTC (permalink / raw)
  To: Nicolas Dichtel; +Cc: kbuild-all, davem, netdev, Nicolas Dichtel

Hi Nicolas,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net/master]

url:    https://github.com/0day-ci/linux/commits/Nicolas-Dichtel/ipv6-fix-neighbour-resolution-with-raw-socket/20190621-115455
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
        make ARCH=x86_64 allmodconfig
        make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)

>> drivers/net/vrf.c:363:17: sparse: sparse: incorrect type in assignment (different modifiers) @@    expected struct in6_addr *nexthop @@    got structstruct in6_addr *nexthop @@
>> drivers/net/vrf.c:363:17: sparse:    expected struct in6_addr *nexthop
>> drivers/net/vrf.c:363:17: sparse:    got struct in6_addr const *
   include/net/route.h:356:48: sparse: sparse: incorrect type in argument 2 (different base types) @@    expected unsigned int [usertype] key @@    got restrunsigned int [usertype] key @@
   include/net/route.h:356:48: sparse:    expected unsigned int [usertype] key
   include/net/route.h:356:48: sparse:    got restricted __be32 [usertype] daddr
   include/net/route.h:356:48: sparse: sparse: incorrect type in argument 2 (different base types) @@    expected unsigned int [usertype] key @@    got restrunsigned int [usertype] key @@
   include/net/route.h:356:48: sparse:    expected unsigned int [usertype] key
   include/net/route.h:356:48: sparse:    got restricted __be32 [usertype] daddr
--
>> net/bluetooth/6lowpan.c:188:25: sparse: sparse: incorrect type in assignment (different modifiers) @@    expected struct in6_addr *[assigned] nexthop @@    got t in6_addr *[assigned] nexthop @@
>> net/bluetooth/6lowpan.c:188:25: sparse:    expected struct in6_addr *[assigned] nexthop
>> net/bluetooth/6lowpan.c:188:25: sparse:    got struct in6_addr const *

vim +363 drivers/net/vrf.c

dcdd43c4 David Ahern      2017-03-20  345  
35402e31 David Ahern      2015-10-12  346  #if IS_ENABLED(CONFIG_IPV6)
35402e31 David Ahern      2015-10-12  347  /* modelled after ip6_finish_output2 */
35402e31 David Ahern      2015-10-12  348  static int vrf_finish_output6(struct net *net, struct sock *sk,
35402e31 David Ahern      2015-10-12  349  			      struct sk_buff *skb)
35402e31 David Ahern      2015-10-12  350  {
35402e31 David Ahern      2015-10-12  351  	struct dst_entry *dst = skb_dst(skb);
35402e31 David Ahern      2015-10-12  352  	struct net_device *dev = dst->dev;
35402e31 David Ahern      2015-10-12  353  	struct neighbour *neigh;
35402e31 David Ahern      2015-10-12  354  	struct in6_addr *nexthop;
35402e31 David Ahern      2015-10-12  355  	int ret;
35402e31 David Ahern      2015-10-12  356  
eb63ecc1 David Ahern      2016-12-14  357  	nf_reset(skb);
eb63ecc1 David Ahern      2016-12-14  358  
35402e31 David Ahern      2015-10-12  359  	skb->protocol = htons(ETH_P_IPV6);
35402e31 David Ahern      2015-10-12  360  	skb->dev = dev;
35402e31 David Ahern      2015-10-12  361  
35402e31 David Ahern      2015-10-12  362  	rcu_read_lock_bh();
35402e31 David Ahern      2015-10-12 @363  	nexthop = rt6_nexthop((struct rt6_info *)dst, &ipv6_hdr(skb)->daddr);
35402e31 David Ahern      2015-10-12  364  	neigh = __ipv6_neigh_lookup_noref(dst->dev, nexthop);
35402e31 David Ahern      2015-10-12  365  	if (unlikely(!neigh))
35402e31 David Ahern      2015-10-12  366  		neigh = __neigh_create(&nd_tbl, nexthop, dst->dev, false);
35402e31 David Ahern      2015-10-12  367  	if (!IS_ERR(neigh)) {
4ff06203 Julian Anastasov 2017-02-06  368  		sock_confirm_neigh(skb, neigh);
0353f282 David Ahern      2019-04-05  369  		ret = neigh_output(neigh, skb, false);
35402e31 David Ahern      2015-10-12  370  		rcu_read_unlock_bh();
35402e31 David Ahern      2015-10-12  371  		return ret;
35402e31 David Ahern      2015-10-12  372  	}
35402e31 David Ahern      2015-10-12  373  	rcu_read_unlock_bh();
35402e31 David Ahern      2015-10-12  374  
35402e31 David Ahern      2015-10-12  375  	IP6_INC_STATS(dev_net(dst->dev),
35402e31 David Ahern      2015-10-12  376  		      ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
35402e31 David Ahern      2015-10-12  377  	kfree_skb(skb);
35402e31 David Ahern      2015-10-12  378  	return -EINVAL;
35402e31 David Ahern      2015-10-12  379  }
35402e31 David Ahern      2015-10-12  380  

:::::: The code at line 363 was first introduced by commit
:::::: 35402e31366349a32b505afdfe856aeeb8d939a0 net: Add IPv6 support to VRF device

:::::: TO: David Ahern <dsa@cumulusnetworks.com>
:::::: CC: David S. Miller <davem@davemloft.net>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
  2019-06-20 12:34 [PATCH net] ipv6: fix neighbour resolution with raw socket Nicolas Dichtel
  2019-06-20 15:12 ` David Ahern
  2019-06-21 18:48 ` kbuild test robot
@ 2019-06-23  0:07 ` David Miller
  2019-06-23  0:08   ` David Miller
  2 siblings, 1 reply; 20+ messages in thread
From: David Miller @ 2019-06-23  0:07 UTC (permalink / raw)
  To: nicolas.dichtel; +Cc: netdev

From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 20 Jun 2019 14:34:34 +0200

> The scenario is the following: the user uses a raw socket to send an ipv6
> packet, destinated to a not-connected network, and specify a connected nh.
> Here is the corresponding python script to reproduce this scenario:
 ...
> fd00:175::/64 is a connected route and fd00:200::fa is not a connected
> host.
> 
> With this scenario, the kernel starts by sending a NS to resolve
> fd00:175::2. When it receives the NA, it flushes its queue and try to send
> the initial packet. But instead of sending it, it sends another NS to
> resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
> the user sends again the packet, it now uses the right nh (fd00:175::2).
> 
> The problem is that ip6_dst_lookup_neigh() uses the rt6i_gateway, which is
> :: because the associated route is a connected route, thus it uses the dst
> addr of the packet. Let's use rt6_nexthop() to choose the right nh.
> 
> Note that rt and in6addr_any are const in ip6_dst_lookup_neigh(), thus
> let's constify rt6_nexthop() to avoid ugly cast.
> 
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
  2019-06-23  0:07 ` David Miller
@ 2019-06-23  0:08   ` David Miller
  2019-06-24 14:01     ` [PATCH net v2 0/2] " Nicolas Dichtel
  0 siblings, 1 reply; 20+ messages in thread
From: David Miller @ 2019-06-23  0:08 UTC (permalink / raw)
  To: nicolas.dichtel; +Cc: netdev

From: David Miller <davem@davemloft.net>
Date: Sat, 22 Jun 2019 17:07:12 -0700 (PDT)

> Applied and queued up for -stable, thanks.

Actually, this needs a warning fix in bluetooth and netfilter.  Please
fix this up, do a proper allmodconfig build, and resubmit.

net/bluetooth/6lowpan.c: In function ¡peer_lookup_dst¢:
net/bluetooth/6lowpan.c:188:11: warning: assignment discards ¡const¢ qualifier from pointer target type [-Wdiscarded-qualifiers]
net/netfilter/nf_flow_table_ip.c: In function ¡nf_flow_offload_ipv6_hook¢:
net/netfilter/nf_flow_table_ip.c:481:10: warning: assignment discards ¡const¢ qualifier from pointer target type [-Wdiscarded-qualifiers]

Thank you.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH net v2 0/2] ipv6: fix neighbour resolution with raw socket
  2019-06-23  0:08   ` David Miller
@ 2019-06-24 14:01     ` " Nicolas Dichtel
  2019-06-24 14:01       ` [PATCH net v2 1/2] ipv6: constify rt6_nexthop() Nicolas Dichtel
                         ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Nicolas Dichtel @ 2019-06-24 14:01 UTC (permalink / raw)
  To: davem; +Cc: netdev, ndesaulniers


The first patch prepares the fix, it constify rt6_nexthop().
The detail of the bug is explained in the second patch.

v1 -> v2:
 - fix compilation warnings
 - split the initial patch

 drivers/net/vrf.c                | 2 +-
 include/net/ip6_route.h          | 4 ++--
 net/bluetooth/6lowpan.c          | 4 ++--
 net/ipv6/ip6_output.c            | 2 +-
 net/ipv6/route.c                 | 3 ++-
 net/netfilter/nf_flow_table_ip.c | 2 +-
 6 files changed, 9 insertions(+), 8 deletions(-)

Comments are welcomed,
Regards,
Nicolas


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH net v2 1/2] ipv6: constify rt6_nexthop()
  2019-06-24 14:01     ` [PATCH net v2 0/2] " Nicolas Dichtel
@ 2019-06-24 14:01       ` Nicolas Dichtel
  2019-06-24 16:45         ` Nick Desaulniers
  2019-06-24 14:01       ` [PATCH net v2 2/2] ipv6: fix neighbour resolution with raw socket Nicolas Dichtel
  2019-06-26 20:26       ` [PATCH net v2 0/2] " David Miller
  2 siblings, 1 reply; 20+ messages in thread
From: Nicolas Dichtel @ 2019-06-24 14:01 UTC (permalink / raw)
  To: davem; +Cc: netdev, ndesaulniers, Nicolas Dichtel

There is no functional change in this patch, it only prepares the next one.

rt6_nexthop() will be used by ip6_dst_lookup_neigh(), which uses const
variables.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 drivers/net/vrf.c                | 2 +-
 include/net/ip6_route.h          | 4 ++--
 net/bluetooth/6lowpan.c          | 4 ++--
 net/ipv6/ip6_output.c            | 2 +-
 net/netfilter/nf_flow_table_ip.c | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 11b9525dff27..311b0cc6eb98 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -350,8 +350,8 @@ static int vrf_finish_output6(struct net *net, struct sock *sk,
 {
 	struct dst_entry *dst = skb_dst(skb);
 	struct net_device *dev = dst->dev;
+	const struct in6_addr *nexthop;
 	struct neighbour *neigh;
-	struct in6_addr *nexthop;
 	int ret;
 
 	nf_reset(skb);
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 4790beaa86e0..ee7405e759ba 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -262,8 +262,8 @@ static inline bool ip6_sk_ignore_df(const struct sock *sk)
 	       inet6_sk(sk)->pmtudisc == IPV6_PMTUDISC_OMIT;
 }
 
-static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt,
-					   struct in6_addr *daddr)
+static inline const struct in6_addr *rt6_nexthop(const struct rt6_info *rt,
+						 const struct in6_addr *daddr)
 {
 	if (rt->rt6i_flags & RTF_GATEWAY)
 		return &rt->rt6i_gateway;
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 19d27bee285e..1555b0c6f7ec 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -160,10 +160,10 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
 						  struct in6_addr *daddr,
 						  struct sk_buff *skb)
 {
-	struct lowpan_peer *peer;
-	struct in6_addr *nexthop;
 	struct rt6_info *rt = (struct rt6_info *)skb_dst(skb);
 	int count = atomic_read(&dev->peer_count);
+	const struct in6_addr *nexthop;
+	struct lowpan_peer *peer;
 
 	BT_DBG("peers %d addr %pI6c rt %p", count, daddr, rt);
 
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 834475717110..21efcd02f337 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -59,8 +59,8 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
 {
 	struct dst_entry *dst = skb_dst(skb);
 	struct net_device *dev = dst->dev;
+	const struct in6_addr *nexthop;
 	struct neighbour *neigh;
-	struct in6_addr *nexthop;
 	int ret;
 
 	if (ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr)) {
diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
index 241317473114..cdfc33517e85 100644
--- a/net/netfilter/nf_flow_table_ip.c
+++ b/net/netfilter/nf_flow_table_ip.c
@@ -439,9 +439,9 @@ nf_flow_offload_ipv6_hook(void *priv, struct sk_buff *skb,
 	struct nf_flowtable *flow_table = priv;
 	struct flow_offload_tuple tuple = {};
 	enum flow_offload_tuple_dir dir;
+	const struct in6_addr *nexthop;
 	struct flow_offload *flow;
 	struct net_device *outdev;
-	struct in6_addr *nexthop;
 	struct ipv6hdr *ip6h;
 	struct rt6_info *rt;
 
-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH net v2 2/2] ipv6: fix neighbour resolution with raw socket
  2019-06-24 14:01     ` [PATCH net v2 0/2] " Nicolas Dichtel
  2019-06-24 14:01       ` [PATCH net v2 1/2] ipv6: constify rt6_nexthop() Nicolas Dichtel
@ 2019-06-24 14:01       ` Nicolas Dichtel
  2019-06-26 20:26       ` [PATCH net v2 0/2] " David Miller
  2 siblings, 0 replies; 20+ messages in thread
From: Nicolas Dichtel @ 2019-06-24 14:01 UTC (permalink / raw)
  To: davem; +Cc: netdev, ndesaulniers, Nicolas Dichtel

The scenario is the following: the user uses a raw socket to send an ipv6
packet, destinated to a not-connected network, and specify a connected nh.
Here is the corresponding python script to reproduce this scenario:

 import socket
 IPPROTO_RAW = 255
 send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
 # scapy
 # p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
 # str(p)
 req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
 send_s.sendto(req, ('fd00:175::2', 0, 0, 0))

fd00:175::/64 is a connected route and fd00:200::fa is not a connected
host.

With this scenario, the kernel starts by sending a NS to resolve
fd00:175::2. When it receives the NA, it flushes its queue and try to send
the initial packet. But instead of sending it, it sends another NS to
resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
the user sends again the packet, it now uses the right nh (fd00:175::2).

The problem is that ip6_dst_lookup_neigh() uses the rt6i_gateway, which is
:: because the associated route is a connected route, thus it uses the dst
addr of the packet. Let's use rt6_nexthop() to choose the right nh.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 net/ipv6/route.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 11ad62effd56..b6449bc03f11 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -218,7 +218,8 @@ static struct neighbour *ip6_dst_neigh_lookup(const struct dst_entry *dst,
 {
 	const struct rt6_info *rt = container_of(dst, struct rt6_info, dst);
 
-	return ip6_neigh_lookup(&rt->rt6i_gateway, dst->dev, skb, daddr);
+	return ip6_neigh_lookup(rt6_nexthop(rt, &in6addr_any),
+				dst->dev, skb, daddr);
 }
 
 static void ip6_confirm_neigh(const struct dst_entry *dst, const void *daddr)
-- 
2.21.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net v2 1/2] ipv6: constify rt6_nexthop()
  2019-06-24 14:01       ` [PATCH net v2 1/2] ipv6: constify rt6_nexthop() Nicolas Dichtel
@ 2019-06-24 16:45         ` Nick Desaulniers
  2019-06-24 17:06           ` David Miller
  0 siblings, 1 reply; 20+ messages in thread
From: Nick Desaulniers @ 2019-06-24 16:45 UTC (permalink / raw)
  To: Nicolas Dichtel; +Cc: David S. Miller, netdev, kbuild test robot

On Mon, Jun 24, 2019 at 7:01 AM Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
>
> There is no functional change in this patch, it only prepares the next one.
>
> rt6_nexthop() will be used by ip6_dst_lookup_neigh(), which uses const
> variables.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>

Also, I think this fixes an issues reported by 0day:
https://groups.google.com/forum/#!searchin/clang-built-linux/const%7Csort:date/clang-built-linux/umkS84jS9m8/GAVVEgNYBgAJ

Reported-by: kbuild test robot <lkp@intel.com>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>

> ---
>  drivers/net/vrf.c                | 2 +-
>  include/net/ip6_route.h          | 4 ++--
>  net/bluetooth/6lowpan.c          | 4 ++--
>  net/ipv6/ip6_output.c            | 2 +-
>  net/netfilter/nf_flow_table_ip.c | 2 +-
>  5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
> index 11b9525dff27..311b0cc6eb98 100644
> --- a/drivers/net/vrf.c
> +++ b/drivers/net/vrf.c
> @@ -350,8 +350,8 @@ static int vrf_finish_output6(struct net *net, struct sock *sk,
>  {
>         struct dst_entry *dst = skb_dst(skb);
>         struct net_device *dev = dst->dev;
> +       const struct in6_addr *nexthop;
>         struct neighbour *neigh;
> -       struct in6_addr *nexthop;
>         int ret;
>
>         nf_reset(skb);
> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> index 4790beaa86e0..ee7405e759ba 100644
> --- a/include/net/ip6_route.h
> +++ b/include/net/ip6_route.h
> @@ -262,8 +262,8 @@ static inline bool ip6_sk_ignore_df(const struct sock *sk)
>                inet6_sk(sk)->pmtudisc == IPV6_PMTUDISC_OMIT;
>  }
>
> -static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt,
> -                                          struct in6_addr *daddr)
> +static inline const struct in6_addr *rt6_nexthop(const struct rt6_info *rt,
> +                                                const struct in6_addr *daddr)
>  {
>         if (rt->rt6i_flags & RTF_GATEWAY)
>                 return &rt->rt6i_gateway;
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index 19d27bee285e..1555b0c6f7ec 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -160,10 +160,10 @@ static inline struct lowpan_peer *peer_lookup_dst(struct lowpan_btle_dev *dev,
>                                                   struct in6_addr *daddr,
>                                                   struct sk_buff *skb)
>  {
> -       struct lowpan_peer *peer;
> -       struct in6_addr *nexthop;
>         struct rt6_info *rt = (struct rt6_info *)skb_dst(skb);
>         int count = atomic_read(&dev->peer_count);
> +       const struct in6_addr *nexthop;
> +       struct lowpan_peer *peer;

I see the added const, but I'm not sure why the declarations were
reordered?  Here and below. Doesn't matter for code review (doesn't
necessitate a v2).

>
>         BT_DBG("peers %d addr %pI6c rt %p", count, daddr, rt);
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 834475717110..21efcd02f337 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -59,8 +59,8 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
>  {
>         struct dst_entry *dst = skb_dst(skb);
>         struct net_device *dev = dst->dev;
> +       const struct in6_addr *nexthop;
>         struct neighbour *neigh;
> -       struct in6_addr *nexthop;
>         int ret;
>
>         if (ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr)) {
> diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
> index 241317473114..cdfc33517e85 100644
> --- a/net/netfilter/nf_flow_table_ip.c
> +++ b/net/netfilter/nf_flow_table_ip.c
> @@ -439,9 +439,9 @@ nf_flow_offload_ipv6_hook(void *priv, struct sk_buff *skb,
>         struct nf_flowtable *flow_table = priv;
>         struct flow_offload_tuple tuple = {};
>         enum flow_offload_tuple_dir dir;
> +       const struct in6_addr *nexthop;
>         struct flow_offload *flow;
>         struct net_device *outdev;
> -       struct in6_addr *nexthop;
>         struct ipv6hdr *ip6h;
>         struct rt6_info *rt;
>
> --
> 2.21.0
>


-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net v2 1/2] ipv6: constify rt6_nexthop()
  2019-06-24 16:45         ` Nick Desaulniers
@ 2019-06-24 17:06           ` David Miller
  2019-06-24 17:17             ` Nick Desaulniers
  0 siblings, 1 reply; 20+ messages in thread
From: David Miller @ 2019-06-24 17:06 UTC (permalink / raw)
  To: ndesaulniers; +Cc: nicolas.dichtel, netdev, lkp

From: Nick Desaulniers <ndesaulniers@google.com>
Date: Mon, 24 Jun 2019 09:45:14 -0700

> https://groups.google.com/forum/#!searchin/clang-built-linux/const%7Csort:date/clang-built-linux/umkS84jS9m8/GAVVEgNYBgAJ

Inaccessible...

	This group either doesn't exist, or you don't have permission
	to access it. If you're sure this group exists, contact the
	Owner of the group and ask them to give you access.

And you mean just changing to 'const' fixes something, how?

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net v2 1/2] ipv6: constify rt6_nexthop()
  2019-06-24 17:06           ` David Miller
@ 2019-06-24 17:17             ` Nick Desaulniers
  2019-06-24 17:22               ` David Miller
  0 siblings, 1 reply; 20+ messages in thread
From: Nick Desaulniers @ 2019-06-24 17:17 UTC (permalink / raw)
  To: David Miller; +Cc: Nicolas Dichtel, netdev, kbuild test robot

On Mon, Jun 24, 2019 at 10:06 AM David Miller <davem@davemloft.net> wrote:
>
> From: Nick Desaulniers <ndesaulniers@google.com>
> Date: Mon, 24 Jun 2019 09:45:14 -0700
>
> > https://groups.google.com/forum/#!searchin/clang-built-linux/const%7Csort:date/clang-built-linux/umkS84jS9m8/GAVVEgNYBgAJ
>
> Inaccessible...
>
>         This group either doesn't exist, or you don't have permission
>         to access it. If you're sure this group exists, contact the
>         Owner of the group and ask them to give you access.

Sorry, I set up the mailing list not too long ago, seem to have a long
tail of permissions related issues.  I confirmed that the link was
borked in an incognito window.  Via
https://support.google.com/a/answer/9325317#Visibility I was able to
change the obscure setting.  I now confirmed the above link works in
an incognito window.  Thanks for reporting; can you please triple
check?

>
> And you mean just changing to 'const' fixes something, how?

See the warning in the above link (assuming now you have access).
Assigning a non-const variable the result of a function call that
returns const discards the const qualifier.

-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net v2 1/2] ipv6: constify rt6_nexthop()
  2019-06-24 17:17             ` Nick Desaulniers
@ 2019-06-24 17:22               ` David Miller
  2019-06-24 17:37                 ` Nick Desaulniers
  0 siblings, 1 reply; 20+ messages in thread
From: David Miller @ 2019-06-24 17:22 UTC (permalink / raw)
  To: ndesaulniers; +Cc: nicolas.dichtel, netdev, lkp

From: Nick Desaulniers <ndesaulniers@google.com>
Date: Mon, 24 Jun 2019 10:17:03 -0700

> On Mon, Jun 24, 2019 at 10:06 AM David Miller <davem@davemloft.net> wrote:
>>
>> From: Nick Desaulniers <ndesaulniers@google.com>
>> Date: Mon, 24 Jun 2019 09:45:14 -0700
>>
>> > https://groups.google.com/forum/#!searchin/clang-built-linux/const%7Csort:date/clang-built-linux/umkS84jS9m8/GAVVEgNYBgAJ
>>
>> Inaccessible...
>>
>>         This group either doesn't exist, or you don't have permission
>>         to access it. If you're sure this group exists, contact the
>>         Owner of the group and ask them to give you access.
> 
> Sorry, I set up the mailing list not too long ago, seem to have a long
> tail of permissions related issues.  I confirmed that the link was
> borked in an incognito window.  Via
> https://support.google.com/a/answer/9325317#Visibility I was able to
> change the obscure setting.  I now confirmed the above link works in
> an incognito window.  Thanks for reporting; can you please triple
> check?

Yep it works now, thanks.

>>
>> And you mean just changing to 'const' fixes something, how?
> 
> See the warning in the above link (assuming now you have access).
> Assigning a non-const variable the result of a function call that
> returns const discards the const qualifier.

Ok thanks for clarifying.

However I was speaking in terms of this fixing a functional bug rather
than a loss of const warning.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net v2 1/2] ipv6: constify rt6_nexthop()
  2019-06-24 17:22               ` David Miller
@ 2019-06-24 17:37                 ` Nick Desaulniers
  2019-06-24 18:18                   ` Nicolas Dichtel
  0 siblings, 1 reply; 20+ messages in thread
From: Nick Desaulniers @ 2019-06-24 17:37 UTC (permalink / raw)
  To: David Miller, Nicolas Dichtel; +Cc: netdev, kbuild test robot

On Mon, Jun 24, 2019 at 10:22 AM David Miller <davem@davemloft.net> wrote:
>
> From: Nick Desaulniers <ndesaulniers@google.com>
> Date: Mon, 24 Jun 2019 10:17:03 -0700
>
> > On Mon, Jun 24, 2019 at 10:06 AM David Miller <davem@davemloft.net> wrote:
> >> And you mean just changing to 'const' fixes something, how?
> >
> > See the warning in the above link (assuming now you have access).
> > Assigning a non-const variable the result of a function call that
> > returns const discards the const qualifier.
>
> Ok thanks for clarifying.
>
> However I was speaking in terms of this fixing a functional bug rather
> than a loss of const warning.

The author stated that this patch was no functional change.  Nicolas,
it can be helpful to include compiler warnings in the commit message
when sending warning fixes, but it's not a big deal.  Thanks for
sending the patches.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net v2 1/2] ipv6: constify rt6_nexthop()
  2019-06-24 17:37                 ` Nick Desaulniers
@ 2019-06-24 18:18                   ` Nicolas Dichtel
  2019-06-24 20:27                     ` David Miller
  0 siblings, 1 reply; 20+ messages in thread
From: Nicolas Dichtel @ 2019-06-24 18:18 UTC (permalink / raw)
  To: Nick Desaulniers, David Miller; +Cc: netdev, kbuild test robot

Le 24/06/2019 à 19:37, Nick Desaulniers a écrit :
[snip]
> 
> The author stated that this patch was no functional change.  Nicolas,
> it can be helpful to include compiler warnings in the commit message
> when sending warning fixes, but it's not a big deal.  Thanks for
> sending the patches.
> 
Yep, but I was not aware of this compilation warning. As explained in the commit
log, the goal of this patch was to prepare the next one.


Regards,
Nicolas

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net v2 1/2] ipv6: constify rt6_nexthop()
  2019-06-24 18:18                   ` Nicolas Dichtel
@ 2019-06-24 20:27                     ` David Miller
  0 siblings, 0 replies; 20+ messages in thread
From: David Miller @ 2019-06-24 20:27 UTC (permalink / raw)
  To: nicolas.dichtel; +Cc: ndesaulniers, netdev, lkp

From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 24 Jun 2019 20:18:37 +0200

> Le 24/06/2019 à 19:37, Nick Desaulniers a écrit :
> [snip]
>> 
>> The author stated that this patch was no functional change.  Nicolas,
>> it can be helpful to include compiler warnings in the commit message
>> when sending warning fixes, but it's not a big deal.  Thanks for
>> sending the patches.
>> 
> Yep, but I was not aware of this compilation warning. As explained in the commit
> log, the goal of this patch was to prepare the next one.

Yeah, don't worry about it.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH net v2 0/2] ipv6: fix neighbour resolution with raw socket
  2019-06-24 14:01     ` [PATCH net v2 0/2] " Nicolas Dichtel
  2019-06-24 14:01       ` [PATCH net v2 1/2] ipv6: constify rt6_nexthop() Nicolas Dichtel
  2019-06-24 14:01       ` [PATCH net v2 2/2] ipv6: fix neighbour resolution with raw socket Nicolas Dichtel
@ 2019-06-26 20:26       ` " David Miller
  2 siblings, 0 replies; 20+ messages in thread
From: David Miller @ 2019-06-26 20:26 UTC (permalink / raw)
  To: nicolas.dichtel; +Cc: netdev, ndesaulniers

From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 24 Jun 2019 16:01:07 +0200

> The first patch prepares the fix, it constify rt6_nexthop().
> The detail of the bug is explained in the second patch.
> 
> v1 -> v2:
>  - fix compilation warnings
>  - split the initial patch

Series applied, thanks Nicolas.

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, back to index

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-20 12:34 [PATCH net] ipv6: fix neighbour resolution with raw socket Nicolas Dichtel
2019-06-20 15:12 ` David Ahern
2019-06-20 15:42   ` Nicolas Dichtel
2019-06-20 16:36     ` David Ahern
2019-06-20 16:47       ` David Ahern
2019-06-21  8:09       ` Nicolas Dichtel
2019-06-21 18:48 ` kbuild test robot
2019-06-23  0:07 ` David Miller
2019-06-23  0:08   ` David Miller
2019-06-24 14:01     ` [PATCH net v2 0/2] " Nicolas Dichtel
2019-06-24 14:01       ` [PATCH net v2 1/2] ipv6: constify rt6_nexthop() Nicolas Dichtel
2019-06-24 16:45         ` Nick Desaulniers
2019-06-24 17:06           ` David Miller
2019-06-24 17:17             ` Nick Desaulniers
2019-06-24 17:22               ` David Miller
2019-06-24 17:37                 ` Nick Desaulniers
2019-06-24 18:18                   ` Nicolas Dichtel
2019-06-24 20:27                     ` David Miller
2019-06-24 14:01       ` [PATCH net v2 2/2] ipv6: fix neighbour resolution with raw socket Nicolas Dichtel
2019-06-26 20:26       ` [PATCH net v2 0/2] " David Miller

Netdev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git
	git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \
		netdev@vger.kernel.org netdev@archiver.kernel.org
	public-inbox-index netdev


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netdev


AGPL code for this site: git clone https://public-inbox.org/ public-inbox