<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net/ipv6, branch v5.3</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.3</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.3'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2019-09-12T10:20:33Z</updated>
<entry>
<title>ipv6: Fix the link time qualifier of 'ping_v6_proc_exit_net()'</title>
<updated>2019-09-12T10:20:33Z</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2019-09-10T11:29:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d23dbc479a8e813db4161a695d67da0e36557846'/>
<id>urn:sha1:d23dbc479a8e813db4161a695d67da0e36557846</id>
<content type='text'>
The '.exit' functions from 'pernet_operations' structure should be marked
as __net_exit, not __net_init.

Fixes: d862e5461423 ("net: ipv6: Implement /proc/net/icmp6.")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: addrconf_f6i_alloc - fix non-null pointer check to !IS_ERR()</title>
<updated>2019-09-07T15:46:44Z</updated>
<author>
<name>Maciej Żenczykowski</name>
<email>maze@google.com</email>
</author>
<published>2019-09-06T03:56:37Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8652f17c658d03f5c87b8dee6e8e52480c6cd37d'/>
<id>urn:sha1:8652f17c658d03f5c87b8dee6e8e52480c6cd37d</id>
<content type='text'>
Fixes a stupid bug I recently introduced...
ip6_route_info_create() returns an ERR_PTR(err) and not a NULL on error.

Fixes: d55a2e374a94 ("net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)'")
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Lorenzo Colitti &lt;lorenzo@google.com&gt;
Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Maciej Żenczykowski &lt;maze@google.com&gt;
Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Properly update v4 routes with v6 nexthop</title>
<updated>2019-09-05T10:35:58Z</updated>
<author>
<name>Donald Sharp</name>
<email>sharpd@cumulusnetworks.com</email>
</author>
<published>2019-09-04T14:11:58Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7bdf4de1267780aa194b3a28c85a6c4d617b0bdb'/>
<id>urn:sha1:7bdf4de1267780aa194b3a28c85a6c4d617b0bdb</id>
<content type='text'>
When creating a v4 route that uses a v6 nexthop from a nexthop group.
Allow the kernel to properly send the nexthop as v6 via the RTA_VIA
attribute.

Broken behavior:

$ ip nexthop add via fe80::9 dev eth0
$ ip nexthop show
id 1 via fe80::9 dev eth0 scope link
$ ip route add 4.5.6.7/32 nhid 1
$ ip route show
default via 10.0.2.2 dev eth0
4.5.6.7 nhid 1 via 254.128.0.0 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
$

Fixed behavior:

$ ip nexthop add via fe80::9 dev eth0
$ ip nexthop show
id 1 via fe80::9 dev eth0 scope link
$ ip route add 4.5.6.7/32 nhid 1
$ ip route show
default via 10.0.2.2 dev eth0
4.5.6.7 nhid 1 via inet6 fe80::9 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
$

v2, v3: Addresses code review comments from David Ahern

Fixes: dcb1ecb50edf (“ipv4: Prepare for fib6_nh from a nexthop object”)
Signed-off-by: Donald Sharp &lt;sharpd@cumulusnetworks.com&gt;
Reviewed-by: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: Fix RTA_MULTIPATH with nexthop objects</title>
<updated>2019-09-05T09:59:39Z</updated>
<author>
<name>David Ahern</name>
<email>dsahern@gmail.com</email>
</author>
<published>2019-09-03T22:22:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=4255ff0544ee307e9a8acf66000e6fd49e9203f8'/>
<id>urn:sha1:4255ff0544ee307e9a8acf66000e6fd49e9203f8</id>
<content type='text'>
A change to the core nla helpers was missed during the push of
the nexthop changes. rt6_fill_node_nexthop should be calling
nla_nest_start_noflag not nla_nest_start. Currently, iproute2
does not print multipath data because of parsing issues with
the attribute.

Fixes: f88d8ea67fbd ("ipv6: Plumb support for nexthop object in a fib6_info")
Signed-off-by: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)</title>
<updated>2019-09-04T22:31:50Z</updated>
<author>
<name>Maciej Żenczykowski</name>
<email>maze@google.com</email>
</author>
<published>2019-09-02T16:23:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d55a2e374a94fa34a3048c6a2be535266e506d97'/>
<id>urn:sha1:d55a2e374a94fa34a3048c6a2be535266e506d97</id>
<content type='text'>
There is a subtle change in behaviour introduced by:
  commit c7a1ce397adacaf5d4bb2eab0a738b5f80dc3e43
  'ipv6: Change addrconf_f6i_alloc to use ip6_route_info_create'

Before that patch /proc/net/ipv6_route includes:
00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000003 00000000 80200001 lo

Afterwards /proc/net/ipv6_route includes:
00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00000000 80240001 lo

ie. the above commit causes the ::1/128 local (automatic) route to be flagged with RTF_ADDRCONF (0x040000).

AFAICT, this is incorrect since these routes are *not* coming from RA's.

As such, this patch restores the old behaviour.

Fixes: c7a1ce397ada ("ipv6: Change addrconf_f6i_alloc to use ip6_route_info_create")
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Lorenzo Colitti &lt;lorenzo@google.com&gt;
Signed-off-by: Maciej Żenczykowski &lt;maze@google.com&gt;
Reviewed-by: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>mld: fix memory leak in mld_del_delrec()</title>
<updated>2019-08-28T21:47:35Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2019-08-27T10:33:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a84d016479896b5526a2cc54784e6ffc41c9d6f6'/>
<id>urn:sha1:a84d016479896b5526a2cc54784e6ffc41c9d6f6</id>
<content type='text'>
Similar to the fix done for IPv4 in commit e5b1c6c6277d
("igmp: fix memory leak in igmpv3_del_delrec()"), we need to
make sure mca_tomb and mca_sources are not blindly overwritten.

Using swap() then a call to ip6_mc_clear_src() will take care
of the missing free.

BUG: memory leak
unreferenced object 0xffff888117d9db00 (size 64):
  comm "syz-executor247", pid 6918, jiffies 4294943989 (age 25.350s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 fe 88 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;000000005b463030&gt;] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
    [&lt;000000005b463030&gt;] slab_post_alloc_hook mm/slab.h:522 [inline]
    [&lt;000000005b463030&gt;] slab_alloc mm/slab.c:3319 [inline]
    [&lt;000000005b463030&gt;] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
    [&lt;00000000939cbf94&gt;] kmalloc include/linux/slab.h:552 [inline]
    [&lt;00000000939cbf94&gt;] kzalloc include/linux/slab.h:748 [inline]
    [&lt;00000000939cbf94&gt;] ip6_mc_add1_src net/ipv6/mcast.c:2236 [inline]
    [&lt;00000000939cbf94&gt;] ip6_mc_add_src+0x31f/0x420 net/ipv6/mcast.c:2356
    [&lt;00000000d8972221&gt;] ip6_mc_source+0x4a8/0x600 net/ipv6/mcast.c:449
    [&lt;000000002b203d0d&gt;] do_ipv6_setsockopt.isra.0+0x1b92/0x1dd0 net/ipv6/ipv6_sockglue.c:748
    [&lt;000000001f1e2d54&gt;] ipv6_setsockopt+0x89/0xd0 net/ipv6/ipv6_sockglue.c:944
    [&lt;00000000c8f7bdf9&gt;] udpv6_setsockopt+0x4e/0x90 net/ipv6/udp.c:1558
    [&lt;000000005a9a0c5e&gt;] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3139
    [&lt;00000000910b37b2&gt;] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
    [&lt;00000000e9108023&gt;] __do_sys_setsockopt net/socket.c:2100 [inline]
    [&lt;00000000e9108023&gt;] __se_sys_setsockopt net/socket.c:2097 [inline]
    [&lt;00000000e9108023&gt;] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2097
    [&lt;00000000f4818160&gt;] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296
    [&lt;000000008d367e8f&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 1666d49e1d41 ("mld: do not remove mld souce list info when set link down")
Fixes: 9c8bb163ae78 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: propagate ipv6_add_dev's error returns out of ipv6_find_idev</title>
<updated>2019-08-23T21:53:06Z</updated>
<author>
<name>Sabrina Dubroca</name>
<email>sd@queasysnail.net</email>
</author>
<published>2019-08-23T13:44:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=db0b99f59ae4d934a0af1a5670706d7c2a4b58ea'/>
<id>urn:sha1:db0b99f59ae4d934a0af1a5670706d7c2a4b58ea</id>
<content type='text'>
Currently, ipv6_find_idev returns NULL when ipv6_add_dev fails,
ignoring the specific error value. This results in addrconf_add_dev
returning ENOBUFS in all cases, which is unfortunate in cases such as:

    # ip link add dummyX type dummy
    # ip link set dummyX mtu 1200 up
    # ip addr add 2000::/64 dev dummyX
    RTNETLINK answers: No buffer space available

Commit a317a2f19da7 ("ipv6: fail early when creating netdev named all
or default") introduced error returns in ipv6_add_dev. Before that,
that function would simply return NULL for all failures.

Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set</title>
<updated>2019-08-22T03:39:29Z</updated>
<author>
<name>Hangbin Liu</name>
<email>liuhangbin@gmail.com</email>
</author>
<published>2019-08-20T02:19:47Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f17f7648a49aa6728649ddf79bdbcac4f1970ce4'/>
<id>urn:sha1:f17f7648a49aa6728649ddf79bdbcac4f1970ce4</id>
<content type='text'>
In commit 93a714d6b53d ("multicast: Extend ip address command to enable
multicast group join/leave on") we added a new flag IFA_F_MCAUTOJOIN
to make user able to add multicast address on ethernet interface.

This works for IPv4, but not for IPv6. See the inet6_addr_add code.

static int inet6_addr_add()
{
	...
	if (cfg-&gt;ifa_flags &amp; IFA_F_MCAUTOJOIN) {
		ipv6_mc_config(net-&gt;ipv6.mc_autojoin_sk, true...)
	}

	ifp = ipv6_add_addr(idev, cfg, true, extack); &lt;- always fail with maddr
	if (!IS_ERR(ifp)) {
		...
	} else if (cfg-&gt;ifa_flags &amp; IFA_F_MCAUTOJOIN) {
		ipv6_mc_config(net-&gt;ipv6.mc_autojoin_sk, false...)
	}
}

But in ipv6_add_addr() it will check the address type and reject multicast
address directly. So this feature is never worked for IPv6.

We should not remove the multicast address check totally in ipv6_add_addr(),
but could accept multicast address only when IFA_F_MCAUTOJOIN flag supplied.

v2: update commit description

Fixes: 93a714d6b53d ("multicast: Extend ip address command to enable multicast group join/leave on")
Reported-by: Jianlin Shi &lt;jishi@redhat.com&gt;
Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>inet: frags: re-introduce skb coalescing for local delivery</title>
<updated>2019-08-08T22:55:10Z</updated>
<author>
<name>Guillaume Nault</name>
<email>gnault@redhat.com</email>
</author>
<published>2019-08-02T15:15:03Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=891584f48a9084ba462f10da4c6bb28b6181b543'/>
<id>urn:sha1:891584f48a9084ba462f10da4c6bb28b6181b543</id>
<content type='text'>
Before commit d4289fcc9b16 ("net: IP6 defrag: use rbtrees for IPv6
defrag"), a netperf UDP_STREAM test[0] using big IPv6 datagrams (thus
generating many fragments) and running over an IPsec tunnel, reported
more than 6Gbps throughput. After that patch, the same test gets only
9Mbps when receiving on a be2net nic (driver can make a big difference
here, for example, ixgbe doesn't seem to be affected).

By reusing the IPv4 defragmentation code, IPv6 lost fragment coalescing
(IPv4 fragment coalescing was dropped by commit 14fe22e33462 ("Revert
"ipv4: use skb coalescing in defragmentation"")).

Without fragment coalescing, be2net runs out of Rx ring entries and
starts to drop frames (ethtool reports rx_drops_no_frags errors). Since
the netperf traffic is only composed of UDP fragments, any lost packet
prevents reassembly of the full datagram. Therefore, fragments which
have no possibility to ever get reassembled pile up in the reassembly
queue, until the memory accounting exeeds the threshold. At that point
no fragment is accepted anymore, which effectively discards all
netperf traffic.

When reassembly timeout expires, some stale fragments are removed from
the reassembly queue, so a few packets can be received, reassembled
and delivered to the netperf receiver. But the nic still drops frames
and soon the reassembly queue gets filled again with stale fragments.
These long time frames where no datagram can be received explain why
the performance drop is so significant.

Re-introducing fragment coalescing is enough to get the initial
performances again (6.6Gbps with be2net): driver doesn't drop frames
anymore (no more rx_drops_no_frags errors) and the reassembly engine
works at full speed.

This patch is quite conservative and only coalesces skbs for local
IPv4 and IPv6 delivery (in order to avoid changing skb geometry when
forwarding). Coalescing could be extended in the future if need be, as
more scenarios would probably benefit from it.

[0]: Test configuration
Sender:
ip xfrm policy flush
ip xfrm state flush
ip xfrm state add src fc00:1::1 dst fc00:2::1 proto esp spi 0x1000 aead 'rfc4106(gcm(aes))' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 96 mode transport sel src fc00:1::1 dst fc00:2::1
ip xfrm policy add src fc00:1::1 dst fc00:2::1 dir in tmpl src fc00:1::1 dst fc00:2::1 proto esp mode transport action allow
ip xfrm state add src fc00:2::1 dst fc00:1::1 proto esp spi 0x1001 aead 'rfc4106(gcm(aes))' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 96 mode transport sel src fc00:2::1 dst fc00:1::1
ip xfrm policy add src fc00:2::1 dst fc00:1::1 dir out tmpl src fc00:2::1 dst fc00:1::1 proto esp mode transport action allow
netserver -D -L fc00:2::1

Receiver:
ip xfrm policy flush
ip xfrm state flush
ip xfrm state add src fc00:2::1 dst fc00:1::1 proto esp spi 0x1001 aead 'rfc4106(gcm(aes))' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 96 mode transport sel src fc00:2::1 dst fc00:1::1
ip xfrm policy add src fc00:2::1 dst fc00:1::1 dir in tmpl src fc00:2::1 dst fc00:1::1 proto esp mode transport action allow
ip xfrm state add src fc00:1::1 dst fc00:2::1 proto esp spi 0x1000 aead 'rfc4106(gcm(aes))' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b 96 mode transport sel src fc00:1::1 dst fc00:2::1
ip xfrm policy add src fc00:1::1 dst fc00:2::1 dir out tmpl src fc00:1::1 dst fc00:2::1 proto esp mode transport action allow
netperf -H fc00:2::1 -f k -P 0 -L fc00:1::1 -l 60 -t UDP_STREAM -I 99,5 -i 5,5 -T5,5 -6

Signed-off-by: Guillaume Nault &lt;gnault@redhat.com&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: Fix unbalanced rcu locking in rt6_update_exception_stamp_rt</title>
<updated>2019-08-05T20:16:58Z</updated>
<author>
<name>David Ahern</name>
<email>dsahern@gmail.com</email>
</author>
<published>2019-08-01T21:36:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=cff6a327d78b05c98e0d1c4be77225ea2c0bfe8e'/>
<id>urn:sha1:cff6a327d78b05c98e0d1c4be77225ea2c0bfe8e</id>
<content type='text'>
The nexthop path in rt6_update_exception_stamp_rt needs to call
rcu_read_unlock if it fails to find a fib6_nh match rather than
just returning.

Fixes: e659ba31d806 ("ipv6: Handle all fib6_nh in a nexthop in exception handling")
Signed-off-by: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
