<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net/ipv6, branch v4.2.3</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>ipv6: fix multipath route replace error recovery</title>
<updated>2015-10-03T11:51:36+00:00</updated>
<author>
<name>Roopa Prabhu</name>
<email>roopa@cumulusnetworks.com</email>
</author>
<published>2015-09-08T17:53:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e60f4a39c2173ad637d5c6541404b7847acac246'/>
<id>e60f4a39c2173ad637d5c6541404b7847acac246</id>
<content type='text'>
[ Upstream commit 6b9ea5a64ed5eeb3f68f2e6fcce0ed1179801d1e ]

Problem:
The ecmp route replace support for ipv6 in the kernel, deletes the
existing ecmp route too early, ie when it installs the first nexthop.
If there is an error in installing the subsequent nexthops, its too late
to recover the already deleted existing route leaving the fib
in an inconsistent state.

This patch reduces the possibility of this by doing the following:
a) Changes the existing multipath route add code to a two stage process:
  build rt6_infos + insert them
	ip6_route_add rt6_info creation code is moved into
	ip6_route_info_create.
b) This ensures that most errors are caught during building rt6_infos
  and we fail early
c) Separates multipath add and del code. Because add needs the special
  two stage mode in a) and delete essentially does not care.
d) In any event if the code fails during inserting a route again, a
  warning is printed (This should be unlikely)

Before the patch:
$ip -6 route show
3000:1000:1000:1000::2 via fe80::202:ff:fe00:b dev swp49s0 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:d dev swp49s1 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:f dev swp49s2 metric 1024

/* Try replacing the route with a duplicate nexthop */
$ip -6 route change 3000:1000:1000:1000::2/128 nexthop via
fe80::202:ff:fe00:b dev swp49s0 nexthop via fe80::202:ff:fe00:d dev
swp49s1 nexthop via fe80::202:ff:fe00:d dev swp49s1
RTNETLINK answers: File exists

$ip -6 route show
/* previously added ecmp route 3000:1000:1000:1000::2 dissappears from
 * kernel */

After the patch:
$ip -6 route show
3000:1000:1000:1000::2 via fe80::202:ff:fe00:b dev swp49s0 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:d dev swp49s1 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:f dev swp49s2 metric 1024

/* Try replacing the route with a duplicate nexthop */
$ip -6 route change 3000:1000:1000:1000::2/128 nexthop via
fe80::202:ff:fe00:b dev swp49s0 nexthop via fe80::202:ff:fe00:d dev
swp49s1 nexthop via fe80::202:ff:fe00:d dev swp49s1
RTNETLINK answers: File exists

$ip -6 route show
3000:1000:1000:1000::2 via fe80::202:ff:fe00:b dev swp49s0 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:d dev swp49s1 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:f dev swp49s2 metric 1024

Fixes: 27596472473a ("ipv6: fix ECMP route replacement")
Signed-off-by: Roopa Prabhu &lt;roopa@cumulusnetworks.com&gt;
Reviewed-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Acked-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 6b9ea5a64ed5eeb3f68f2e6fcce0ed1179801d1e ]

Problem:
The ecmp route replace support for ipv6 in the kernel, deletes the
existing ecmp route too early, ie when it installs the first nexthop.
If there is an error in installing the subsequent nexthops, its too late
to recover the already deleted existing route leaving the fib
in an inconsistent state.

This patch reduces the possibility of this by doing the following:
a) Changes the existing multipath route add code to a two stage process:
  build rt6_infos + insert them
	ip6_route_add rt6_info creation code is moved into
	ip6_route_info_create.
b) This ensures that most errors are caught during building rt6_infos
  and we fail early
c) Separates multipath add and del code. Because add needs the special
  two stage mode in a) and delete essentially does not care.
d) In any event if the code fails during inserting a route again, a
  warning is printed (This should be unlikely)

Before the patch:
$ip -6 route show
3000:1000:1000:1000::2 via fe80::202:ff:fe00:b dev swp49s0 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:d dev swp49s1 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:f dev swp49s2 metric 1024

/* Try replacing the route with a duplicate nexthop */
$ip -6 route change 3000:1000:1000:1000::2/128 nexthop via
fe80::202:ff:fe00:b dev swp49s0 nexthop via fe80::202:ff:fe00:d dev
swp49s1 nexthop via fe80::202:ff:fe00:d dev swp49s1
RTNETLINK answers: File exists

$ip -6 route show
/* previously added ecmp route 3000:1000:1000:1000::2 dissappears from
 * kernel */

After the patch:
$ip -6 route show
3000:1000:1000:1000::2 via fe80::202:ff:fe00:b dev swp49s0 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:d dev swp49s1 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:f dev swp49s2 metric 1024

/* Try replacing the route with a duplicate nexthop */
$ip -6 route change 3000:1000:1000:1000::2/128 nexthop via
fe80::202:ff:fe00:b dev swp49s0 nexthop via fe80::202:ff:fe00:d dev
swp49s1 nexthop via fe80::202:ff:fe00:d dev swp49s1
RTNETLINK answers: File exists

$ip -6 route show
3000:1000:1000:1000::2 via fe80::202:ff:fe00:b dev swp49s0 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:d dev swp49s1 metric 1024
3000:1000:1000:1000::2 via fe80::202:ff:fe00:f dev swp49s2 metric 1024

Fixes: 27596472473a ("ipv6: fix ECMP route replacement")
Signed-off-by: Roopa Prabhu &lt;roopa@cumulusnetworks.com&gt;
Reviewed-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Acked-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/ipv6: Correct PIM6 mrt_lock handling</title>
<updated>2015-10-03T11:51:35+00:00</updated>
<author>
<name>Richard Laing</name>
<email>richard.laing@alliedtelesis.co.nz</email>
</author>
<published>2015-09-03T01:52:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f5f10834321f31c4b08f4f9760e0857cfa90add4'/>
<id>f5f10834321f31c4b08f4f9760e0857cfa90add4</id>
<content type='text'>
[ Upstream commit 25b4a44c19c83d98e8c0807a7ede07c1f28eab8b ]

In the IPv6 multicast routing code the mrt_lock was not being released
correctly in the MFC iterator, as a result adding or deleting a MIF would
cause a hang because the mrt_lock could not be acquired.

This fix is a copy of the code for the IPv4 case and ensures that the lock
is released correctly.

Signed-off-by: Richard Laing &lt;richard.laing@alliedtelesis.co.nz&gt;
Acked-by: Cong Wang &lt;cwang@twopensource.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 25b4a44c19c83d98e8c0807a7ede07c1f28eab8b ]

In the IPv6 multicast routing code the mrt_lock was not being released
correctly in the MFC iterator, as a result adding or deleting a MIF would
cause a hang because the mrt_lock could not be acquired.

This fix is a copy of the code for the IPv4 case and ensures that the lock
is released correctly.

Signed-off-by: Richard Laing &lt;richard.laing@alliedtelesis.co.nz&gt;
Acked-by: Cong Wang &lt;cwang@twopensource.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: fix exthdrs offload registration in out_rt path</title>
<updated>2015-10-03T11:51:35+00:00</updated>
<author>
<name>Daniel Borkmann</name>
<email>daniel@iogearbox.net</email>
</author>
<published>2015-09-02T22:29:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=dd35e5b8ad3ddcb3dd13e076ba87e16fd4bd2e99'/>
<id>dd35e5b8ad3ddcb3dd13e076ba87e16fd4bd2e99</id>
<content type='text'>
[ Upstream commit e41b0bedba0293b9e1e8d1e8ed553104b9693656 ]

We previously register IPPROTO_ROUTING offload under inet6_add_offload(),
but in error path, we try to unregister it with inet_del_offload(). This
doesn't seem correct, it should actually be inet6_del_offload(), also
ipv6_exthdrs_offload_exit() from that commit seems rather incorrect (it
also uses rthdr_offload twice), but it got removed entirely later on.

Fixes: 3336288a9fea ("ipv6: Switch to using new offload infrastructure.")
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e41b0bedba0293b9e1e8d1e8ed553104b9693656 ]

We previously register IPPROTO_ROUTING offload under inet6_add_offload(),
but in error path, we try to unregister it with inet_del_offload(). This
doesn't seem correct, it should actually be inet6_del_offload(), also
ipv6_exthdrs_offload_exit() from that commit seems rather incorrect (it
also uses rthdr_offload twice), but it got removed entirely later on.

Fixes: 3336288a9fea ("ipv6: Switch to using new offload infrastructure.")
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ip6_gre: release cached dst on tunnel removal</title>
<updated>2015-08-25T21:33:00+00:00</updated>
<author>
<name>huaibin Wang</name>
<email>huaibin.wang@6wind.com</email>
</author>
<published>2015-08-25T14:20:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d4257295ba1b389c693b79de857a96e4b7cd8ac0'/>
<id>d4257295ba1b389c693b79de857a96e4b7cd8ac0</id>
<content type='text'>
When a tunnel is deleted, the cached dst entry should be released.

This problem may prevent the removal of a netns (seen with a x-netns IPv6
gre tunnel):
  unregister_netdevice: waiting for lo to become free. Usage count = 3

CC: Dmitry Kozlov &lt;xeb@mail.ru&gt;
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: huaibin Wang &lt;huaibin.wang@6wind.com&gt;
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When a tunnel is deleted, the cached dst entry should be released.

This problem may prevent the removal of a netns (seen with a x-netns IPv6
gre tunnel):
  unregister_netdevice: waiting for lo to become free. Usage count = 3

CC: Dmitry Kozlov &lt;xeb@mail.ru&gt;
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: huaibin Wang &lt;huaibin.wang@6wind.com&gt;
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: Fix a potential deadlock when creating pcpu rt</title>
<updated>2015-08-17T21:28:03+00:00</updated>
<author>
<name>Martin KaFai Lau</name>
<email>kafai@fb.com</email>
</author>
<published>2015-08-14T18:05:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9c7370a166b4e157137bfbfe2ad296d57147547c'/>
<id>9c7370a166b4e157137bfbfe2ad296d57147547c</id>
<content type='text'>
rt6_make_pcpu_route() is called under read_lock(&amp;table-&gt;tb6_lock).
rt6_make_pcpu_route() calls ip6_rt_pcpu_alloc(rt) which then
calls dst_alloc().  dst_alloc() _may_ call ip6_dst_gc() which takes
the write_lock(&amp;tabl-&gt;tb6_lock).  A visualized version:

read_lock(&amp;table-&gt;tb6_lock);
rt6_make_pcpu_route();
=&gt; ip6_rt_pcpu_alloc();
=&gt; dst_alloc();
=&gt; ip6_dst_gc();
=&gt; write_lock(&amp;table-&gt;tb6_lock); /* oops */

The fix is to do a read_unlock first before calling ip6_rt_pcpu_alloc().

A reported stack:

[141625.537638] INFO: rcu_sched self-detected stall on CPU { 27}  (t=60000 jiffies g=4159086 c=4159085 q=2139)
[141625.547469] Task dump for CPU 27:
[141625.550881] mtr             R  running task        0 22121  22081 0x00000008
[141625.558069]  0000000000000000 ffff88103f363d98 ffffffff8106e488 000000000000001b
[141625.565641]  ffffffff81684900 ffff88103f363db8 ffffffff810702b0 0000000008000000
[141625.573220]  ffffffff81684900 ffff88103f363de8 ffffffff8108df9f ffff88103f375a00
[141625.580803] Call Trace:
[141625.583345]  &lt;IRQ&gt;  [&lt;ffffffff8106e488&gt;] sched_show_task+0xc1/0xc6
[141625.589650]  [&lt;ffffffff810702b0&gt;] dump_cpu_task+0x35/0x39
[141625.595144]  [&lt;ffffffff8108df9f&gt;] rcu_dump_cpu_stacks+0x6a/0x8c
[141625.601320]  [&lt;ffffffff81090606&gt;] rcu_check_callbacks+0x1f6/0x5d4
[141625.607669]  [&lt;ffffffff810940c8&gt;] update_process_times+0x2a/0x4f
[141625.613925]  [&lt;ffffffff8109fbee&gt;] tick_sched_handle+0x32/0x3e
[141625.619923]  [&lt;ffffffff8109fc2f&gt;] tick_sched_timer+0x35/0x5c
[141625.625830]  [&lt;ffffffff81094a1f&gt;] __hrtimer_run_queues+0x8f/0x18d
[141625.632171]  [&lt;ffffffff81094c9e&gt;] hrtimer_interrupt+0xa0/0x166
[141625.638258]  [&lt;ffffffff8102bf2a&gt;] local_apic_timer_interrupt+0x4e/0x52
[141625.645036]  [&lt;ffffffff8102c36f&gt;] smp_apic_timer_interrupt+0x39/0x4a
[141625.651643]  [&lt;ffffffff8140b9e8&gt;] apic_timer_interrupt+0x68/0x70
[141625.657895]  &lt;EOI&gt;  [&lt;ffffffff81346ee8&gt;] ? dst_destroy+0x7c/0xb5
[141625.664188]  [&lt;ffffffff813d45b5&gt;] ? fib6_flush_trees+0x20/0x20
[141625.670272]  [&lt;ffffffff81082b45&gt;] ? queue_write_lock_slowpath+0x60/0x6f
[141625.677140]  [&lt;ffffffff8140aa33&gt;] _raw_write_lock_bh+0x23/0x25
[141625.683218]  [&lt;ffffffff813d4553&gt;] __fib6_clean_all+0x40/0x82
[141625.689124]  [&lt;ffffffff813d45b5&gt;] ? fib6_flush_trees+0x20/0x20
[141625.695207]  [&lt;ffffffff813d6058&gt;] fib6_clean_all+0xe/0x10
[141625.700854]  [&lt;ffffffff813d60d3&gt;] fib6_run_gc+0x79/0xc8
[141625.706329]  [&lt;ffffffff813d0510&gt;] ip6_dst_gc+0x85/0xf9
[141625.711718]  [&lt;ffffffff81346d68&gt;] dst_alloc+0x55/0x159
[141625.717105]  [&lt;ffffffff813d09b5&gt;] __ip6_dst_alloc.isra.32+0x19/0x63
[141625.723620]  [&lt;ffffffff813d1830&gt;] ip6_pol_route+0x36a/0x3e8
[141625.729441]  [&lt;ffffffff813d18d6&gt;] ip6_pol_route_output+0x11/0x13
[141625.735700]  [&lt;ffffffff813f02c8&gt;] fib6_rule_action+0xa7/0x1bf
[141625.741698]  [&lt;ffffffff813d18c5&gt;] ? ip6_pol_route_input+0x17/0x17
[141625.748043]  [&lt;ffffffff81357c48&gt;] fib_rules_lookup+0xb5/0x12a
[141625.754050]  [&lt;ffffffff81141628&gt;] ? poll_select_copy_remaining+0xf9/0xf9
[141625.761002]  [&lt;ffffffff813f0535&gt;] fib6_rule_lookup+0x37/0x5c
[141625.766914]  [&lt;ffffffff813d18c5&gt;] ? ip6_pol_route_input+0x17/0x17
[141625.773260]  [&lt;ffffffff813d008c&gt;] ip6_route_output+0x7a/0x82
[141625.779177]  [&lt;ffffffff813c44c8&gt;] ip6_dst_lookup_tail+0x53/0x112
[141625.785437]  [&lt;ffffffff813c45c3&gt;] ip6_dst_lookup_flow+0x2a/0x6b
[141625.791604]  [&lt;ffffffff813ddaab&gt;] rawv6_sendmsg+0x407/0x9b6
[141625.797423]  [&lt;ffffffff813d7914&gt;] ? do_ipv6_setsockopt.isra.8+0xd87/0xde2
[141625.804464]  [&lt;ffffffff8139d4b4&gt;] inet_sendmsg+0x57/0x8e
[141625.810028]  [&lt;ffffffff81329ba3&gt;] sock_sendmsg+0x2e/0x3c
[141625.815588]  [&lt;ffffffff8132be57&gt;] SyS_sendto+0xfe/0x143
[141625.821063]  [&lt;ffffffff813dd551&gt;] ? rawv6_setsockopt+0x5e/0x67
[141625.827146]  [&lt;ffffffff8132c9f8&gt;] ? sock_common_setsockopt+0xf/0x11
[141625.833660]  [&lt;ffffffff8132c08c&gt;] ? SyS_setsockopt+0x81/0xa2
[141625.839565]  [&lt;ffffffff8140ac17&gt;] entry_SYSCALL_64_fastpath+0x12/0x6a

Fixes: d52d3997f843 ("pv6: Create percpu rt6_info")
Signed-off-by: Martin KaFai Lau &lt;kafai@fb.com&gt;
CC: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Reported-by: Steinar H. Gunderson &lt;sgunderson@bigfoot.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
rt6_make_pcpu_route() is called under read_lock(&amp;table-&gt;tb6_lock).
rt6_make_pcpu_route() calls ip6_rt_pcpu_alloc(rt) which then
calls dst_alloc().  dst_alloc() _may_ call ip6_dst_gc() which takes
the write_lock(&amp;tabl-&gt;tb6_lock).  A visualized version:

read_lock(&amp;table-&gt;tb6_lock);
rt6_make_pcpu_route();
=&gt; ip6_rt_pcpu_alloc();
=&gt; dst_alloc();
=&gt; ip6_dst_gc();
=&gt; write_lock(&amp;table-&gt;tb6_lock); /* oops */

The fix is to do a read_unlock first before calling ip6_rt_pcpu_alloc().

A reported stack:

[141625.537638] INFO: rcu_sched self-detected stall on CPU { 27}  (t=60000 jiffies g=4159086 c=4159085 q=2139)
[141625.547469] Task dump for CPU 27:
[141625.550881] mtr             R  running task        0 22121  22081 0x00000008
[141625.558069]  0000000000000000 ffff88103f363d98 ffffffff8106e488 000000000000001b
[141625.565641]  ffffffff81684900 ffff88103f363db8 ffffffff810702b0 0000000008000000
[141625.573220]  ffffffff81684900 ffff88103f363de8 ffffffff8108df9f ffff88103f375a00
[141625.580803] Call Trace:
[141625.583345]  &lt;IRQ&gt;  [&lt;ffffffff8106e488&gt;] sched_show_task+0xc1/0xc6
[141625.589650]  [&lt;ffffffff810702b0&gt;] dump_cpu_task+0x35/0x39
[141625.595144]  [&lt;ffffffff8108df9f&gt;] rcu_dump_cpu_stacks+0x6a/0x8c
[141625.601320]  [&lt;ffffffff81090606&gt;] rcu_check_callbacks+0x1f6/0x5d4
[141625.607669]  [&lt;ffffffff810940c8&gt;] update_process_times+0x2a/0x4f
[141625.613925]  [&lt;ffffffff8109fbee&gt;] tick_sched_handle+0x32/0x3e
[141625.619923]  [&lt;ffffffff8109fc2f&gt;] tick_sched_timer+0x35/0x5c
[141625.625830]  [&lt;ffffffff81094a1f&gt;] __hrtimer_run_queues+0x8f/0x18d
[141625.632171]  [&lt;ffffffff81094c9e&gt;] hrtimer_interrupt+0xa0/0x166
[141625.638258]  [&lt;ffffffff8102bf2a&gt;] local_apic_timer_interrupt+0x4e/0x52
[141625.645036]  [&lt;ffffffff8102c36f&gt;] smp_apic_timer_interrupt+0x39/0x4a
[141625.651643]  [&lt;ffffffff8140b9e8&gt;] apic_timer_interrupt+0x68/0x70
[141625.657895]  &lt;EOI&gt;  [&lt;ffffffff81346ee8&gt;] ? dst_destroy+0x7c/0xb5
[141625.664188]  [&lt;ffffffff813d45b5&gt;] ? fib6_flush_trees+0x20/0x20
[141625.670272]  [&lt;ffffffff81082b45&gt;] ? queue_write_lock_slowpath+0x60/0x6f
[141625.677140]  [&lt;ffffffff8140aa33&gt;] _raw_write_lock_bh+0x23/0x25
[141625.683218]  [&lt;ffffffff813d4553&gt;] __fib6_clean_all+0x40/0x82
[141625.689124]  [&lt;ffffffff813d45b5&gt;] ? fib6_flush_trees+0x20/0x20
[141625.695207]  [&lt;ffffffff813d6058&gt;] fib6_clean_all+0xe/0x10
[141625.700854]  [&lt;ffffffff813d60d3&gt;] fib6_run_gc+0x79/0xc8
[141625.706329]  [&lt;ffffffff813d0510&gt;] ip6_dst_gc+0x85/0xf9
[141625.711718]  [&lt;ffffffff81346d68&gt;] dst_alloc+0x55/0x159
[141625.717105]  [&lt;ffffffff813d09b5&gt;] __ip6_dst_alloc.isra.32+0x19/0x63
[141625.723620]  [&lt;ffffffff813d1830&gt;] ip6_pol_route+0x36a/0x3e8
[141625.729441]  [&lt;ffffffff813d18d6&gt;] ip6_pol_route_output+0x11/0x13
[141625.735700]  [&lt;ffffffff813f02c8&gt;] fib6_rule_action+0xa7/0x1bf
[141625.741698]  [&lt;ffffffff813d18c5&gt;] ? ip6_pol_route_input+0x17/0x17
[141625.748043]  [&lt;ffffffff81357c48&gt;] fib_rules_lookup+0xb5/0x12a
[141625.754050]  [&lt;ffffffff81141628&gt;] ? poll_select_copy_remaining+0xf9/0xf9
[141625.761002]  [&lt;ffffffff813f0535&gt;] fib6_rule_lookup+0x37/0x5c
[141625.766914]  [&lt;ffffffff813d18c5&gt;] ? ip6_pol_route_input+0x17/0x17
[141625.773260]  [&lt;ffffffff813d008c&gt;] ip6_route_output+0x7a/0x82
[141625.779177]  [&lt;ffffffff813c44c8&gt;] ip6_dst_lookup_tail+0x53/0x112
[141625.785437]  [&lt;ffffffff813c45c3&gt;] ip6_dst_lookup_flow+0x2a/0x6b
[141625.791604]  [&lt;ffffffff813ddaab&gt;] rawv6_sendmsg+0x407/0x9b6
[141625.797423]  [&lt;ffffffff813d7914&gt;] ? do_ipv6_setsockopt.isra.8+0xd87/0xde2
[141625.804464]  [&lt;ffffffff8139d4b4&gt;] inet_sendmsg+0x57/0x8e
[141625.810028]  [&lt;ffffffff81329ba3&gt;] sock_sendmsg+0x2e/0x3c
[141625.815588]  [&lt;ffffffff8132be57&gt;] SyS_sendto+0xfe/0x143
[141625.821063]  [&lt;ffffffff813dd551&gt;] ? rawv6_setsockopt+0x5e/0x67
[141625.827146]  [&lt;ffffffff8132c9f8&gt;] ? sock_common_setsockopt+0xf/0x11
[141625.833660]  [&lt;ffffffff8132c08c&gt;] ? SyS_setsockopt+0x81/0xa2
[141625.839565]  [&lt;ffffffff8140ac17&gt;] entry_SYSCALL_64_fastpath+0x12/0x6a

Fixes: d52d3997f843 ("pv6: Create percpu rt6_info")
Signed-off-by: Martin KaFai Lau &lt;kafai@fb.com&gt;
CC: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Reported-by: Steinar H. Gunderson &lt;sgunderson@bigfoot.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: Add rt6_make_pcpu_route()</title>
<updated>2015-08-17T21:28:03+00:00</updated>
<author>
<name>Martin KaFai Lau</name>
<email>kafai@fb.com</email>
</author>
<published>2015-08-14T18:05:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a73e4195636c17f310b8530643a576f42b82385f'/>
<id>a73e4195636c17f310b8530643a576f42b82385f</id>
<content type='text'>
It is a prep work for fixing a potential deadlock when creating
a pcpu rt.

The current rt6_get_pcpu_route() will also create a pcpu rt if one does not
exist.  This patch moves the pcpu rt creation logic into another function,
rt6_make_pcpu_route().

Signed-off-by: Martin KaFai Lau &lt;kafai@fb.com&gt;
CC: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is a prep work for fixing a potential deadlock when creating
a pcpu rt.

The current rt6_get_pcpu_route() will also create a pcpu rt if one does not
exist.  This patch moves the pcpu rt creation logic into another function,
rt6_make_pcpu_route().

Signed-off-by: Martin KaFai Lau &lt;kafai@fb.com&gt;
CC: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: Remove un-used argument from ip6_dst_alloc()</title>
<updated>2015-08-17T21:28:03+00:00</updated>
<author>
<name>Martin KaFai Lau</name>
<email>kafai@fb.com</email>
</author>
<published>2015-08-14T18:05:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ad706862890171e02df1d7391b05599fb676ec18'/>
<id>ad706862890171e02df1d7391b05599fb676ec18</id>
<content type='text'>
After 4b32b5ad31a6 ("ipv6: Stop rt6_info from using inet_peer's metrics"),
ip6_dst_alloc() does not need the 'table' argument.  This patch
cleans it up.

Signed-off-by: Martin KaFai Lau &lt;kafai@fb.com&gt;
CC: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After 4b32b5ad31a6 ("ipv6: Stop rt6_info from using inet_peer's metrics"),
ip6_dst_alloc() does not need the 'table' argument.  This patch
cleans it up.

Signed-off-by: Martin KaFai Lau &lt;kafai@fb.com&gt;
CC: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code</title>
<updated>2015-08-14T00:08:39+00:00</updated>
<author>
<name>Linus Lüssing</name>
<email>linus.luessing@c0d3.blue</email>
</author>
<published>2015-08-13T03:54:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a516993f0ac1694673412eb2d16a091eafa77d2a'/>
<id>a516993f0ac1694673412eb2d16a091eafa77d2a</id>
<content type='text'>
The recent refactoring of the IGMP and MLD parsing code into
ipv6_mc_check_mld() / ip_mc_check_igmp() introduced a potential crash /
BUG() invocation for bridges:

I wrongly assumed that skb_get() could be used as a simple reference
counter for an skb which is not the case. skb_get() bears additional
semantics, a user count. This leads to a BUG() invocation in
pskb_expand_head() / kernel panic if pskb_may_pull() is called on an skb
with a user count greater than one - unfortunately the refactoring did
just that.

Fixing this by removing the skb_get() call and changing the API: The
caller of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to
additionally check whether the returned skb_trimmed is a clone.

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Brenden Blanco &lt;bblanco@plumgrid.com&gt;
Signed-off-by: Linus Lüssing &lt;linus.luessing@c0d3.blue&gt;
Acked-by: Alexei Starovoitov &lt;ast@plumgrid.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The recent refactoring of the IGMP and MLD parsing code into
ipv6_mc_check_mld() / ip_mc_check_igmp() introduced a potential crash /
BUG() invocation for bridges:

I wrongly assumed that skb_get() could be used as a simple reference
counter for an skb which is not the case. skb_get() bears additional
semantics, a user count. This leads to a BUG() invocation in
pskb_expand_head() / kernel panic if pskb_may_pull() is called on an skb
with a user count greater than one - unfortunately the refactoring did
just that.

Fixing this by removing the skb_get() call and changing the API: The
caller of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to
additionally check whether the returned skb_trimmed is a clone.

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Brenden Blanco &lt;bblanco@plumgrid.com&gt;
Signed-off-by: Linus Lüssing &lt;linus.luessing@c0d3.blue&gt;
Acked-by: Alexei Starovoitov &lt;ast@plumgrid.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>inet: fix possible request socket leak</title>
<updated>2015-08-11T04:17:45+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-08-10T22:07:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3257d8b12f954c462d29de6201664a846328a522'/>
<id>3257d8b12f954c462d29de6201664a846328a522</id>
<content type='text'>
In commit b357a364c57c9 ("inet: fix possible panic in
reqsk_queue_unlink()"), I missed fact that tcp_check_req()
can return the listener socket in one case, and that we must
release the request socket refcount or we leak it.

Tested:

 Following packetdrill test template shows the issue

0     socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0    setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0    bind(3, ..., ...) = 0
+0    listen(3, 1) = 0

+0    &lt; S 0:0(0) win 2920 &lt;mss 1460,sackOK,nop,nop&gt;
+0    &gt; S. 0:0(0) ack 1 &lt;mss 1460,nop,nop,sackOK&gt;
+.002 &lt; . 1:1(0) ack 21 win 2920
+0    &gt; R 21:21(0)

Fixes: b357a364c57c9 ("inet: fix possible panic in reqsk_queue_unlink()")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In commit b357a364c57c9 ("inet: fix possible panic in
reqsk_queue_unlink()"), I missed fact that tcp_check_req()
can return the listener socket in one case, and that we must
release the request socket refcount or we leak it.

Tested:

 Following packetdrill test template shows the issue

0     socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0    setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0    bind(3, ..., ...) = 0
+0    listen(3, 1) = 0

+0    &lt; S 0:0(0) win 2920 &lt;mss 1460,sackOK,nop,nop&gt;
+0    &gt; S. 0:0(0) ack 1 &lt;mss 1460,nop,nop,sackOK&gt;
+.002 &lt; . 1:1(0) ack 21 win 2920
+0    &gt; R 21:21(0)

Fixes: b357a364c57c9 ("inet: fix possible panic in reqsk_queue_unlink()")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf</title>
<updated>2015-08-11T04:03:25+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-08-11T04:03:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=182554570a3f01457202206ac784b488cd190f75'/>
<id>182554570a3f01457202206ac784b488cd190f75</id>
<content type='text'>
Pablo Neira Ayuso says:

====================
Netfilter fixes for net

The following patchset contains five Netfilter fixes for your net tree,
they are:

1) Silence a warning on falling back to vmalloc(). Since 88eab472ec21, we can
   easily hit this warning message, that gets users confused. So let's get rid
   of it.

2) Recently when porting the template object allocation on top of kmalloc to
   fix the netns dependencies between x_tables and conntrack, the error
   checks where left unchanged. Remove IS_ERR() and check for NULL instead.
   Patch from Dan Carpenter.

3) Don't ignore gfp_flags in the new nf_ct_tmpl_alloc() function, from
   Joe Stringer.

4) Fix a crash due to NULL pointer dereference in ip6t_SYNPROXY, patch from
   Phil Sutter.

5) The sequence number of the Syn+ack that is sent from SYNPROXY to clients is
   not adjusted through our NAT infrastructure, as a result the client may
   ignore this TCP packet and TCP flow hangs until the client probes us.  Also
   from Phil Sutter.
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pablo Neira Ayuso says:

====================
Netfilter fixes for net

The following patchset contains five Netfilter fixes for your net tree,
they are:

1) Silence a warning on falling back to vmalloc(). Since 88eab472ec21, we can
   easily hit this warning message, that gets users confused. So let's get rid
   of it.

2) Recently when porting the template object allocation on top of kmalloc to
   fix the netns dependencies between x_tables and conntrack, the error
   checks where left unchanged. Remove IS_ERR() and check for NULL instead.
   Patch from Dan Carpenter.

3) Don't ignore gfp_flags in the new nf_ct_tmpl_alloc() function, from
   Joe Stringer.

4) Fix a crash due to NULL pointer dereference in ip6t_SYNPROXY, patch from
   Phil Sutter.

5) The sequence number of the Syn+ack that is sent from SYNPROXY to clients is
   not adjusted through our NAT infrastructure, as a result the client may
   ignore this TCP packet and TCP flow hangs until the client probes us.  Also
   from Phil Sutter.
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
