<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/ipv4/ipmr.c, branch v4.4-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2015-11-03T18:41:45+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-11-03T18:41:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=73186df8d7fa574345f0ad626ebe89649f8308a5'/>
<id>73186df8d7fa574345f0ad626ebe89649f8308a5</id>
<content type='text'>
Minor overlapping changes in net/ipv4/ipmr.c, in 'net' we were
fixing the "BH-ness" of the counter bumps whilst in 'net-next'
the functions were modified to take an explicit 'net' parameter.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Minor overlapping changes in net/ipv4/ipmr.c, in 'net' we were
fixing the "BH-ness" of the counter bumps whilst in 'net-next'
the functions were modified to take an explicit 'net' parameter.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.</title>
<updated>2015-11-02T20:57:12+00:00</updated>
<author>
<name>Ani Sinha</name>
<email>ani@arista.com</email>
</author>
<published>2015-10-30T23:54:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=44f49dd8b5a606870a1f21101522a0f9c4414784'/>
<id>44f49dd8b5a606870a1f21101522a0f9c4414784</id>
<content type='text'>
Fixes the following kernel BUG :

BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758
caller is __this_cpu_preempt_check+0x13/0x15
CPU: 0 PID: 2758 Comm: bash Tainted: P           O   3.18.19 #2
 ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000
 0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800
 ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8
Call Trace:
[&lt;ffffffff81482b2a&gt;] dump_stack+0x52/0x80
[&lt;ffffffff812010ae&gt;] check_preemption_disabled+0xce/0xe1
[&lt;ffffffff812010d4&gt;] __this_cpu_preempt_check+0x13/0x15
[&lt;ffffffff81419d60&gt;] ipmr_queue_xmit+0x647/0x70c
[&lt;ffffffff8141a154&gt;] ip_mr_forward+0x32f/0x34e
[&lt;ffffffff8141af76&gt;] ip_mroute_setsockopt+0xe03/0x108c
[&lt;ffffffff810553fc&gt;] ? get_parent_ip+0x11/0x42
[&lt;ffffffff810e6974&gt;] ? pollwake+0x4d/0x51
[&lt;ffffffff81058ac0&gt;] ? default_wake_function+0x0/0xf
[&lt;ffffffff810553fc&gt;] ? get_parent_ip+0x11/0x42
[&lt;ffffffff810613d9&gt;] ? __wake_up_common+0x45/0x77
[&lt;ffffffff81486ea9&gt;] ? _raw_spin_unlock_irqrestore+0x1d/0x32
[&lt;ffffffff810618bc&gt;] ? __wake_up_sync_key+0x4a/0x53
[&lt;ffffffff8139a519&gt;] ? sock_def_readable+0x71/0x75
[&lt;ffffffff813dd226&gt;] do_ip_setsockopt+0x9d/0xb55
[&lt;ffffffff81429818&gt;] ? unix_seqpacket_sendmsg+0x3f/0x41
[&lt;ffffffff813963fe&gt;] ? sock_sendmsg+0x6d/0x86
[&lt;ffffffff813959d4&gt;] ? sockfd_lookup_light+0x12/0x5d
[&lt;ffffffff8139650a&gt;] ? SyS_sendto+0xf3/0x11b
[&lt;ffffffff810d5738&gt;] ? new_sync_read+0x82/0xaa
[&lt;ffffffff813ddd19&gt;] compat_ip_setsockopt+0x3b/0x99
[&lt;ffffffff813fb24a&gt;] compat_raw_setsockopt+0x11/0x32
[&lt;ffffffff81399052&gt;] compat_sock_common_setsockopt+0x18/0x1f
[&lt;ffffffff813c4d05&gt;] compat_SyS_setsockopt+0x1a9/0x1cf
[&lt;ffffffff813c4149&gt;] compat_SyS_socketcall+0x180/0x1e3
[&lt;ffffffff81488ea1&gt;] cstar_dispatch+0x7/0x1e

Signed-off-by: Ani Sinha &lt;ani@arista.com&gt;
Acked-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>
Fixes the following kernel BUG :

BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758
caller is __this_cpu_preempt_check+0x13/0x15
CPU: 0 PID: 2758 Comm: bash Tainted: P           O   3.18.19 #2
 ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000
 0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800
 ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8
Call Trace:
[&lt;ffffffff81482b2a&gt;] dump_stack+0x52/0x80
[&lt;ffffffff812010ae&gt;] check_preemption_disabled+0xce/0xe1
[&lt;ffffffff812010d4&gt;] __this_cpu_preempt_check+0x13/0x15
[&lt;ffffffff81419d60&gt;] ipmr_queue_xmit+0x647/0x70c
[&lt;ffffffff8141a154&gt;] ip_mr_forward+0x32f/0x34e
[&lt;ffffffff8141af76&gt;] ip_mroute_setsockopt+0xe03/0x108c
[&lt;ffffffff810553fc&gt;] ? get_parent_ip+0x11/0x42
[&lt;ffffffff810e6974&gt;] ? pollwake+0x4d/0x51
[&lt;ffffffff81058ac0&gt;] ? default_wake_function+0x0/0xf
[&lt;ffffffff810553fc&gt;] ? get_parent_ip+0x11/0x42
[&lt;ffffffff810613d9&gt;] ? __wake_up_common+0x45/0x77
[&lt;ffffffff81486ea9&gt;] ? _raw_spin_unlock_irqrestore+0x1d/0x32
[&lt;ffffffff810618bc&gt;] ? __wake_up_sync_key+0x4a/0x53
[&lt;ffffffff8139a519&gt;] ? sock_def_readable+0x71/0x75
[&lt;ffffffff813dd226&gt;] do_ip_setsockopt+0x9d/0xb55
[&lt;ffffffff81429818&gt;] ? unix_seqpacket_sendmsg+0x3f/0x41
[&lt;ffffffff813963fe&gt;] ? sock_sendmsg+0x6d/0x86
[&lt;ffffffff813959d4&gt;] ? sockfd_lookup_light+0x12/0x5d
[&lt;ffffffff8139650a&gt;] ? SyS_sendto+0xf3/0x11b
[&lt;ffffffff810d5738&gt;] ? new_sync_read+0x82/0xaa
[&lt;ffffffff813ddd19&gt;] compat_ip_setsockopt+0x3b/0x99
[&lt;ffffffff813fb24a&gt;] compat_raw_setsockopt+0x11/0x32
[&lt;ffffffff81399052&gt;] compat_sock_common_setsockopt+0x18/0x1f
[&lt;ffffffff813c4d05&gt;] compat_SyS_setsockopt+0x1a9/0x1cf
[&lt;ffffffff813c4149&gt;] compat_SyS_socketcall+0x180/0x1e3
[&lt;ffffffff81488ea1&gt;] cstar_dispatch+0x7/0x1e

Signed-off-by: Ani Sinha &lt;ani@arista.com&gt;
Acked-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>net: Pass net into dst_output and remove dst_output_okfn</title>
<updated>2015-10-08T11:26:54+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2015-10-07T21:48:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=13206b6bff3b15b724926a222406476bf2c23c40'/>
<id>13206b6bff3b15b724926a222406476bf2c23c40</id>
<content type='text'>
Replace dst_output_okfn with dst_output

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.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>
Replace dst_output_okfn with dst_output

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: Pass net into okfn</title>
<updated>2015-09-18T00:18:37+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2015-09-16T01:04:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0c4b51f0054ce85c0ec578ab818f0631834573eb'/>
<id>0c4b51f0054ce85c0ec578ab818f0631834573eb</id>
<content type='text'>
This is immediately motivated by the bridge code that chains functions that
call into netfilter.  Without passing net into the okfns the bridge code would
need to guess about the best expression for the network namespace to process
packets in.

As net is frequently one of the first things computed in continuation functions
after netfilter has done it's job passing in the desired network namespace is in
many cases a code simplification.

To support this change the function dst_output_okfn is introduced to
simplify passing dst_output as an okfn.  For the moment dst_output_okfn
just silently drops the struct net.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.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>
This is immediately motivated by the bridge code that chains functions that
call into netfilter.  Without passing net into the okfns the bridge code would
need to guess about the best expression for the network namespace to process
packets in.

As net is frequently one of the first things computed in continuation functions
after netfilter has done it's job passing in the desired network namespace is in
many cases a code simplification.

To support this change the function dst_output_okfn is introduced to
simplify passing dst_output as an okfn.  For the moment dst_output_okfn
just silently drops the struct net.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: Pass struct net into the netfilter hooks</title>
<updated>2015-09-18T00:18:37+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2015-09-16T01:04:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=29a26a56803855a79dbd028cd61abee56237d6e5'/>
<id>29a26a56803855a79dbd028cd61abee56237d6e5</id>
<content type='text'>
Pass a network namespace parameter into the netfilter hooks.  At the
call site of the netfilter hooks the path a packet is taking through
the network stack is well known which allows the network namespace to
be easily and reliabily.

This allows the replacement of magic code like
"dev_net(state-&gt;in?:state-&gt;out)" that appears at the start of most
netfilter hooks with "state-&gt;net".

In almost all cases the network namespace passed in is derived
from the first network device passed in, guaranteeing those
paths will not see any changes in practice.

The exceptions are:
xfrm/xfrm_output.c:xfrm_output_resume()         xs_net(skb_dst(skb)-&gt;xfrm)
ipvs/ip_vs_xmit.c:ip_vs_nat_send_or_cont()      ip_vs_conn_net(cp)
ipvs/ip_vs_xmit.c:ip_vs_send_or_cont()          ip_vs_conn_net(cp)
ipv4/raw.c:raw_send_hdrinc()                    sock_net(sk)
ipv6/ip6_output.c:ip6_xmit()			sock_net(sk)
ipv6/ndisc.c:ndisc_send_skb()                   dev_net(skb-&gt;dev) not dev_net(dst-&gt;dev)
ipv6/raw.c:raw6_send_hdrinc()                   sock_net(sk)
br_netfilter_hooks.c:br_nf_pre_routing_finish() dev_net(skb-&gt;dev) before skb-&gt;dev is set to nf_bridge-&gt;physindev

In all cases these exceptions seem to be a better expression for the
network namespace the packet is being processed in then the historic
"dev_net(in?in:out)".  I am documenting them in case something odd
pops up and someone starts trying to track down what happened.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.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>
Pass a network namespace parameter into the netfilter hooks.  At the
call site of the netfilter hooks the path a packet is taking through
the network stack is well known which allows the network namespace to
be easily and reliabily.

This allows the replacement of magic code like
"dev_net(state-&gt;in?:state-&gt;out)" that appears at the start of most
netfilter hooks with "state-&gt;net".

In almost all cases the network namespace passed in is derived
from the first network device passed in, guaranteeing those
paths will not see any changes in practice.

The exceptions are:
xfrm/xfrm_output.c:xfrm_output_resume()         xs_net(skb_dst(skb)-&gt;xfrm)
ipvs/ip_vs_xmit.c:ip_vs_nat_send_or_cont()      ip_vs_conn_net(cp)
ipvs/ip_vs_xmit.c:ip_vs_send_or_cont()          ip_vs_conn_net(cp)
ipv4/raw.c:raw_send_hdrinc()                    sock_net(sk)
ipv6/ip6_output.c:ip6_xmit()			sock_net(sk)
ipv6/ndisc.c:ndisc_send_skb()                   dev_net(skb-&gt;dev) not dev_net(dst-&gt;dev)
ipv6/raw.c:raw6_send_hdrinc()                   sock_net(sk)
br_netfilter_hooks.c:br_nf_pre_routing_finish() dev_net(skb-&gt;dev) before skb-&gt;dev is set to nf_bridge-&gt;physindev

In all cases these exceptions seem to be a better expression for the
network namespace the packet is being processed in then the historic
"dev_net(in?in:out)".  I am documenting them in case something odd
pops up and someone starts trying to track down what happened.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv4: Only compute net once in ipmr_forward_finish</title>
<updated>2015-09-18T00:18:34+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2015-09-16T01:04:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=758ccac8e7419ae746bcda807919a547ed9cdaad'/>
<id>758ccac8e7419ae746bcda807919a547ed9cdaad</id>
<content type='text'>
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.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>
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv4: Don't recompute net in ipmr_queue_xmit</title>
<updated>2015-09-18T00:18:33+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2015-09-16T01:03:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cc4c851e4b41d668075d7cb6c71e3725bc5d4662'/>
<id>cc4c851e4b41d668075d7cb6c71e3725bc5d4662</id>
<content type='text'>
Calling dev_net(dev) for is just silly.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.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>
Calling dev_net(dev) for is just silly.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: Merge dst_output and dst_output_sk</title>
<updated>2015-09-18T00:18:32+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2015-09-16T01:03:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5a70649e0dae02ba5090540fffce667d2300bc5a'/>
<id>5a70649e0dae02ba5090540fffce667d2300bc5a</id>
<content type='text'>
Add a sock paramter to dst_output making dst_output_sk superfluous.
Add a skb-&gt;sk parameter to all of the callers of dst_output
Have the callers of dst_output_sk call dst_output.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.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>
Add a sock paramter to dst_output making dst_output_sk superfluous.
Add a skb-&gt;sk parameter to all of the callers of dst_output
Have the callers of dst_output_sk call dst_output.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: ipv6: use common fib_default_rule_pref</title>
<updated>2015-09-09T21:19:50+00:00</updated>
<author>
<name>Phil Sutter</name>
<email>phil@nwl.cc</email>
</author>
<published>2015-09-09T12:20:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f53de1e9a4aaf8cbe08845da6f7ff26a078ac507'/>
<id>f53de1e9a4aaf8cbe08845da6f7ff26a078ac507</id>
<content type='text'>
This switches IPv6 policy routing to use the shared
fib_default_rule_pref() function of IPv4 and DECnet. It is also used in
multicast routing for IPv4 as well as IPv6.

The motivation for this patch is a complaint about iproute2 behaving
inconsistent between IPv4 and IPv6 when adding policy rules: Formerly,
IPv6 rules were assigned a fixed priority of 0x3FFF whereas for IPv4 the
assigned priority value was decreased with each rule added.

Since then all users of the default_pref field have been converted to
assign the generic function fib_default_rule_pref(), fib_nl_newrule()
may just use it directly instead. Therefore get rid of the function
pointer altogether and make fib_default_rule_pref() static, as it's not
used outside fib_rules.c anymore.

Signed-off-by: Phil Sutter &lt;phil@nwl.cc&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>
This switches IPv6 policy routing to use the shared
fib_default_rule_pref() function of IPv4 and DECnet. It is also used in
multicast routing for IPv4 as well as IPv6.

The motivation for this patch is a complaint about iproute2 behaving
inconsistent between IPv4 and IPv6 when adding policy rules: Formerly,
IPv6 rules were assigned a fixed priority of 0x3FFF whereas for IPv4 the
assigned priority value was decreased with each rule added.

Since then all users of the default_pref field have been converted to
assign the generic function fib_default_rule_pref(), fib_nl_newrule()
may just use it directly instead. Therefore get rid of the function
pointer altogether and make fib_default_rule_pref() static, as it's not
used outside fib_rules.c anymore.

Signed-off-by: Phil Sutter &lt;phil@nwl.cc&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: Pass socket pointer down through okfn().</title>
<updated>2015-04-07T19:25:55+00:00</updated>
<author>
<name>David Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-04-06T02:19:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7026b1ddb6b8d4e6ee33dc2bd06c0ca8746fa7ab'/>
<id>7026b1ddb6b8d4e6ee33dc2bd06c0ca8746fa7ab</id>
<content type='text'>
On the output paths in particular, we have to sometimes deal with two
socket contexts.  First, and usually skb-&gt;sk, is the local socket that
generated the frame.

And second, is potentially the socket used to control a tunneling
socket, such as one the encapsulates using UDP.

We do not want to disassociate skb-&gt;sk when encapsulating in order
to fix this, because that would break socket memory accounting.

The most extreme case where this can cause huge problems is an
AF_PACKET socket transmitting over a vxlan device.  We hit code
paths doing checks that assume they are dealing with an ipv4
socket, but are actually operating upon the AF_PACKET one.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On the output paths in particular, we have to sometimes deal with two
socket contexts.  First, and usually skb-&gt;sk, is the local socket that
generated the frame.

And second, is potentially the socket used to control a tunneling
socket, such as one the encapsulates using UDP.

We do not want to disassociate skb-&gt;sk when encapsulating in order
to fix this, because that would break socket memory accounting.

The most extreme case where this can cause huge problems is an
AF_PACKET socket transmitting over a vxlan device.  We hit code
paths doing checks that assume they are dealing with an ipv4
socket, but are actually operating upon the AF_PACKET one.

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