<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net, branch v4.0</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=v4.0</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v4.0'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2015-04-07T16:08:35Z</updated>
<entry>
<title>Revert "libceph: use memalloc flags for net IO"</title>
<updated>2015-04-07T16:08:35Z</updated>
<author>
<name>Ilya Dryomov</name>
<email>idryomov@gmail.com</email>
</author>
<published>2015-04-02T11:40:58Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6d7fdb0ab351b33d4c12d53fe44be030b90fc9d4'/>
<id>urn:sha1:6d7fdb0ab351b33d4c12d53fe44be030b90fc9d4</id>
<content type='text'>
This reverts commit 89baaa570ab0b476db09408d209578cfed700e9f.

Dirty page throttling should be sufficient for us in the general case
so there is no need to use __GFP_MEMALLOC - it would be needed only in
the swap-over-rbd case, which we currently don't support.  (It would
probably take approximately the commit that is being reverted to add
that support, but we would also need the "swap" option to distinguish
from the general case and make sure swap ceph_client-s aren't shared
with anything else.)  See ceph-devel threads [1] and [2] for the
details of why enabling pfmemalloc reserves for all cases is a bad
thing.

On top of potential system lockups related to drained emergency
reserves, this turned out to cause ceph lockups in case peers are on
the same host and communicating via loopback due to sk_filter()
dropping pfmemalloc skbs on the receiving side because the receiving
loopback socket is not tagged with SOCK_MEMALLOC.

[1] "SOCK_MEMALLOC vs loopback"
    http://www.spinics.net/lists/ceph-devel/msg22998.html
[2] "[PATCH] libceph: don't set memalloc flags in loopback case"
    http://www.spinics.net/lists/ceph-devel/msg23392.html

Conflicts:
	net/ceph/messenger.c [ context: tcp_nodelay option ]

Cc: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Cc: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: Sage Weil &lt;sage@redhat.com&gt;
Cc: stable@vger.kernel.org # 3.18+, needs backporting
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Acked-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
</content>
</entry>
<entry>
<title>net: dsa: fix filling routing table from OF description</title>
<updated>2015-04-06T21:31:37Z</updated>
<author>
<name>Pavel Nakonechny</name>
<email>pavel.nakonechny@skitlab.ru</email>
</author>
<published>2015-04-04T21:46:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=303038135afbd0520d1e241c02592be6e4ea7204'/>
<id>urn:sha1:303038135afbd0520d1e241c02592be6e4ea7204</id>
<content type='text'>
According to description in 'include/net/dsa.h', in cascade switches
configurations where there are more than one interconnected devices,
'rtable' array in 'dsa_chip_data' structure is used to indicate which
port on this switch should be used to send packets to that are destined
for corresponding switch.

However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
of the _target_ switch, but not current one.

This commit removes redundant devicetree parsing and adds needed port
number as a function argument. So dsa_of_setup_routing_table() now just
looks for target switch number by parsing parent of 'link' device node.

To remove possible misunderstandings with the way of determining target
switch number, a corresponding comment was added to the source code and
to the DSA device tree bindings documentation file.

This was tested on a custom board with two Marvell 88E6095 switches with
following corresponding routing tables: { -1, 10 } and { 8, -1 }.

Signed-off-by: Pavel Nakonechny &lt;pavel.nakonechny@skitlab.ru&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>l2tp: unregister l2tp_net_ops on failure path</title>
<updated>2015-04-06T20:53:02Z</updated>
<author>
<name>WANG Cong</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2015-04-03T20:46:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=67e04c29ec0daad9ba29341b4dab4b89526994cf'/>
<id>urn:sha1:67e04c29ec0daad9ba29341b4dab4b89526994cf</id>
<content type='text'>
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: protect skb-&gt;sk accesses from recursive dereference inside the stack</title>
<updated>2015-04-06T20:12:49Z</updated>
<author>
<name>hannes@stressinduktion.org</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2015-04-01T15:07:44Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f60e5990d9c1424af9dbca60a23ba2a1c7c1ce90'/>
<id>urn:sha1:f60e5990d9c1424af9dbca60a23ba2a1c7c1ce90</id>
<content type='text'>
We should not consult skb-&gt;sk for output decisions in xmit recursion
levels &gt; 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.

ipv6 does not conform with this in three places:

1) ip6_fragment: we do consult ipv6_npinfo for frag_size

2) sk_mc_loop in ipv6 uses skb-&gt;sk and checks if we should
   loop the packet back to the local socket

3) ip6_skb_dst_mtu could query the settings from the user socket and
   force a wrong MTU

Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.

Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.

Cc: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>netns: don't allocate an id for dead netns</title>
<updated>2015-04-03T16:36:31Z</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2015-04-03T10:02:37Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=576b7cd2f6ff1e90b3fc0a000d2fe74f8a50a4bb'/>
<id>urn:sha1:576b7cd2f6ff1e90b3fc0a000d2fe74f8a50a4bb</id>
<content type='text'>
First, let's explain the problem.
Suppose you have an ipip interface that stands in the netns foo and its link
part in the netns bar (so the netns bar has an nsid into the netns foo).
Now, you remove the netns bar:
 - the bar nsid into the netns foo is removed
 - the netns exit method of ipip is called, thus our ipip iface is removed:
   =&gt; a netlink message is built in the netns foo to advertise this deletion
   =&gt; this netlink message requests an nsid for bar, thus a new nsid is
      allocated for bar and never removed.

This patch adds a check in peernet2id() so that an id cannot be allocated for
a netns which is currently destroyed.

Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Revert "netns: don't clear nsid too early on removal"</title>
<updated>2015-04-03T16:36:31Z</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2015-04-03T10:02:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6d458f5b4ece8542a5c2281e40008823fec91814'/>
<id>urn:sha1:6d458f5b4ece8542a5c2281e40008823fec91814</id>
<content type='text'>
This reverts
commit 4217291e592d ("netns: don't clear nsid too early on removal").

This is not the right fix, it introduces races.

Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ip6mr: call del_timer_sync() in ip6mr_free_table()</title>
<updated>2015-04-03T00:52:35Z</updated>
<author>
<name>WANG Cong</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2015-03-31T18:01:47Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7ba0c47c34a1ea5bc7a24ca67309996cce0569b5'/>
<id>urn:sha1:7ba0c47c34a1ea5bc7a24ca67309996cce0569b5</id>
<content type='text'>
We need to wait for the flying timers, since we
are going to free the mrtable right after it.

Cc: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: move fib_rules_unregister() under rtnl lock</title>
<updated>2015-04-03T00:52:34Z</updated>
<author>
<name>WANG Cong</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2015-03-31T18:01:46Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=419df12fb5fa558451319276838c1842f2b11f8f'/>
<id>urn:sha1:419df12fb5fa558451319276838c1842f2b11f8f</id>
<content type='text'>
We have to hold rtnl lock for fib_rules_unregister()
otherwise the following race could happen:

fib_rules_unregister():	fib_nl_delrule():
...				...
...				ops = lookup_rules_ops();
list_del_rcu(&amp;ops-&gt;list);
				list_for_each_entry(ops-&gt;rules) {
fib_rules_cleanup_ops(ops);	  ...
  list_del_rcu();		  list_del_rcu();
				}

Note, net-&gt;rules_mod_lock is actually not needed at all,
either upper layer netns code or rtnl lock guarantees
we are safe.

Cc: Alexander Duyck &lt;alexander.h.duyck@redhat.com&gt;
Cc: Thomas Graf &lt;tgraf@suug.ch&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup</title>
<updated>2015-04-03T00:52:34Z</updated>
<author>
<name>WANG Cong</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2015-03-31T18:01:45Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ed785309c94445dd90e242370e1f7bb034e008fd'/>
<id>urn:sha1:ed785309c94445dd90e242370e1f7bb034e008fd</id>
<content type='text'>
This is the IPv4 part for commit 905a6f96a1b1
(ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup).

Cc: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: fix FRTO undo on cumulative ACK of SACKed range</title>
<updated>2015-04-02T20:35:58Z</updated>
<author>
<name>Neal Cardwell</name>
<email>ncardwell@google.com</email>
</author>
<published>2015-04-02T00:26:46Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=666b805150efd62f05810ff0db08f44a2370c937'/>
<id>urn:sha1:666b805150efd62f05810ff0db08f44a2370c937</id>
<content type='text'>
On processing cumulative ACKs, the FRTO code was not checking the
SACKed bit, meaning that there could be a spurious FRTO undo on a
cumulative ACK of a previously SACKed skb.

The FRTO code should only consider a cumulative ACK to indicate that
an original/unretransmitted skb is newly ACKed if the skb was not yet
SACKed.

The effect of the spurious FRTO undo would typically be to make the
connection think that all previously-sent packets were in flight when
they really weren't, leading to a stall and an RTO.

Signed-off-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Fixes: e33099f96d99c ("tcp: implement RFC5682 F-RTO")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
