<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/net/ipv4/tcp.c, branch dev</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2015-07-27T08:06:53+00:00</updated>
<entry>
<title>tcp: fix recv with flags MSG_WAITALL | MSG_PEEK</title>
<updated>2015-07-27T08:06:53+00:00</updated>
<author>
<name>Sabrina Dubroca</name>
<email>sd@queasysnail.net</email>
</author>
<published>2015-07-24T16:19:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dfbafc995304ebb9a9b03f65083e6e9cea143b20'/>
<id>urn:sha1:dfbafc995304ebb9a9b03f65083e6e9cea143b20</id>
<content type='text'>
Currently, tcp_recvmsg enters a busy loop in sk_wait_data if called
with flags = MSG_WAITALL | MSG_PEEK.

sk_wait_data waits for sk_receive_queue not empty, but in this case,
the receive queue is not empty, but does not contain any skb that we
can use.

Add a "last skb seen on receive queue" argument to sk_wait_data, so
that it sleeps until the receive queue has new skbs.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=99461
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=18493
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1205258
Reported-by: Enrico Scholz &lt;rh-bugzilla@ensc.de&gt;
Reported-by: Dan Searle &lt;dan@censornet.com&gt;
Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2015-06-24T09:58:51+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-06-24T09:58:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3a07bd6fead4f00f67b1bf5f551e686661c4f52c'/>
<id>urn:sha1:3a07bd6fead4f00f67b1bf5f551e686661c4f52c</id>
<content type='text'>
Conflicts:
	drivers/net/ethernet/mellanox/mlx4/main.c
	net/packet/af_packet.c

Both conflicts were cases of simple overlapping changes.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: Do not call tcp_fastopen_reset_cipher from interrupt context</title>
<updated>2015-06-23T09:38:10+00:00</updated>
<author>
<name>Christoph Paasch</name>
<email>cpaasch@apple.com</email>
</author>
<published>2015-06-18T16:15:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dfea2aa654243f70dc53b8648d0bbdeec55a7df1'/>
<id>urn:sha1:dfea2aa654243f70dc53b8648d0bbdeec55a7df1</id>
<content type='text'>
tcp_fastopen_reset_cipher really cannot be called from interrupt
context. It allocates the tcp_fastopen_context with GFP_KERNEL and
calls crypto_alloc_cipher, which allocates all kind of stuff with
GFP_KERNEL.

Thus, we might sleep when the key-generation is triggered by an
incoming TFO cookie-request which would then happen in interrupt-
context, as shown by enabling CONFIG_DEBUG_ATOMIC_SLEEP:

[   36.001813] BUG: sleeping function called from invalid context at mm/slub.c:1266
[   36.003624] in_atomic(): 1, irqs_disabled(): 0, pid: 1016, name: packetdrill
[   36.004859] CPU: 1 PID: 1016 Comm: packetdrill Not tainted 4.1.0-rc7 #14
[   36.006085] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
[   36.008250]  00000000000004f2 ffff88007f8838a8 ffffffff8171d53a ffff880075a084a8
[   36.009630]  ffff880075a08000 ffff88007f8838c8 ffffffff810967d3 ffff88007f883928
[   36.011076]  0000000000000000 ffff88007f8838f8 ffffffff81096892 ffff88007f89be00
[   36.012494] Call Trace:
[   36.012953]  &lt;IRQ&gt;  [&lt;ffffffff8171d53a&gt;] dump_stack+0x4f/0x6d
[   36.014085]  [&lt;ffffffff810967d3&gt;] ___might_sleep+0x103/0x170
[   36.015117]  [&lt;ffffffff81096892&gt;] __might_sleep+0x52/0x90
[   36.016117]  [&lt;ffffffff8118e887&gt;] kmem_cache_alloc_trace+0x47/0x190
[   36.017266]  [&lt;ffffffff81680d82&gt;] ? tcp_fastopen_reset_cipher+0x42/0x130
[   36.018485]  [&lt;ffffffff81680d82&gt;] tcp_fastopen_reset_cipher+0x42/0x130
[   36.019679]  [&lt;ffffffff81680f01&gt;] tcp_fastopen_init_key_once+0x61/0x70
[   36.020884]  [&lt;ffffffff81680f2c&gt;] __tcp_fastopen_cookie_gen+0x1c/0x60
[   36.022058]  [&lt;ffffffff816814ff&gt;] tcp_try_fastopen+0x58f/0x730
[   36.023118]  [&lt;ffffffff81671788&gt;] tcp_conn_request+0x3e8/0x7b0
[   36.024185]  [&lt;ffffffff810e3872&gt;] ? __module_text_address+0x12/0x60
[   36.025327]  [&lt;ffffffff8167b2e1&gt;] tcp_v4_conn_request+0x51/0x60
[   36.026410]  [&lt;ffffffff816727e0&gt;] tcp_rcv_state_process+0x190/0xda0
[   36.027556]  [&lt;ffffffff81661f97&gt;] ? __inet_lookup_established+0x47/0x170
[   36.028784]  [&lt;ffffffff8167c2ad&gt;] tcp_v4_do_rcv+0x16d/0x3d0
[   36.029832]  [&lt;ffffffff812e6806&gt;] ? security_sock_rcv_skb+0x16/0x20
[   36.030936]  [&lt;ffffffff8167cc8a&gt;] tcp_v4_rcv+0x77a/0x7b0
[   36.031875]  [&lt;ffffffff816af8c3&gt;] ? iptable_filter_hook+0x33/0x70
[   36.032953]  [&lt;ffffffff81657d22&gt;] ip_local_deliver_finish+0x92/0x1f0
[   36.034065]  [&lt;ffffffff81657f1a&gt;] ip_local_deliver+0x9a/0xb0
[   36.035069]  [&lt;ffffffff81657c90&gt;] ? ip_rcv+0x3d0/0x3d0
[   36.035963]  [&lt;ffffffff81657569&gt;] ip_rcv_finish+0x119/0x330
[   36.036950]  [&lt;ffffffff81657ba7&gt;] ip_rcv+0x2e7/0x3d0
[   36.037847]  [&lt;ffffffff81610652&gt;] __netif_receive_skb_core+0x552/0x930
[   36.038994]  [&lt;ffffffff81610a57&gt;] __netif_receive_skb+0x27/0x70
[   36.040033]  [&lt;ffffffff81610b72&gt;] process_backlog+0xd2/0x1f0
[   36.041025]  [&lt;ffffffff81611482&gt;] net_rx_action+0x122/0x310
[   36.042007]  [&lt;ffffffff81076743&gt;] __do_softirq+0x103/0x2f0
[   36.042978]  [&lt;ffffffff81723e3c&gt;] do_softirq_own_stack+0x1c/0x30

This patch moves the call to tcp_fastopen_init_key_once to the places
where a listener socket creates its TFO-state, which always happens in
user-context (either from the setsockopt, or implicitly during the
listen()-call)

Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Fixes: 222e83d2e0ae ("tcp: switch tcp_fastopen key generation to net_get_random_once")
Signed-off-by: Christoph Paasch &lt;cpaasch@apple.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sock_diag: implement a get_info handler for inet</title>
<updated>2015-06-16T02:49:22+00:00</updated>
<author>
<name>Craig Gallek</name>
<email>kraig@google.com</email>
</author>
<published>2015-06-15T15:26:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=35ac838a9b96470f999db04320f53a2033642bfb'/>
<id>urn:sha1:35ac838a9b96470f999db04320f53a2033642bfb</id>
<content type='text'>
This get_info handler will simply dispatch to the appropriate
existing inet protocol handler.

This patch also includes a new netlink attribute
(INET_DIAG_PROTOCOL).  This attribute is currently only used
for multicast messages.  Without this attribute, there is no
way of knowing the IP protocol used by the socket information
being broadcast.  This attribute is not necessary in the 'dump'
variant of this protocol (though it could easily be added)
because dump requests are issued for specific family/protocol
pairs.

Tested: ss -E (note, the -E option has not yet been merged into
the upstream version of ss).

Signed-off-by: Craig Gallek &lt;kraig@google.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: make skb_splice_bits more configureable</title>
<updated>2015-05-25T04:06:59+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2015-05-21T15:00:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a60e3cc7c92973a31fad0fd04dc5cf4355d3d1ef'/>
<id>urn:sha1:a60e3cc7c92973a31fad0fd04dc5cf4355d3d1ef</id>
<content type='text'>
Prepare skb_splice_bits to be able to deal with AF_UNIX sockets.

AF_UNIX sockets don't use lock_sock/release_sock and thus we have to
use a callback to make the locking and unlocking configureable.

Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2015-05-23T05:22:35+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-05-23T05:22:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=36583eb54d46c36a447afd6c379839f292397429'/>
<id>urn:sha1:36583eb54d46c36a447afd6c379839f292397429</id>
<content type='text'>
Conflicts:
	drivers/net/ethernet/cadence/macb.c
	drivers/net/phy/phy.c
	include/linux/skbuff.h
	net/ipv4/tcp.c
	net/switchdev/switchdev.c

Switchdev was a case of RTNH_H_{EXTERNAL --&gt; OFFLOAD}
renaming overlapping with net-next changes of various
sorts.

phy.c was a case of two changes, one adding a local
variable to a function whilst the second was removing
one.

tcp.c overlapped a deadlock fix with the addition of new tcp_info
statistic values.

macb.c involved the addition of two zyncq device entries.

skbuff.h involved adding back ipv4_daddr to nf_bridge_info
whilst net-next changes put two other existing members of
that struct into a union.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: fix a potential deadlock in tcp_get_info()</title>
<updated>2015-05-22T17:46:06+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-05-22T04:51:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d654976cbf852ee20612ee10dbe57cdacda9f452'/>
<id>urn:sha1:d654976cbf852ee20612ee10dbe57cdacda9f452</id>
<content type='text'>
Taking socket spinlock in tcp_get_info() can deadlock, as
inet_diag_dump_icsk() holds the &amp;hashinfo-&gt;ehash_locks[i],
while packet processing can use the reverse locking order.

We could avoid this locking for TCP_LISTEN states, but lockdep would
certainly get confused as all TCP sockets share same lockdep classes.

[  523.722504] ======================================================
[  523.728706] [ INFO: possible circular locking dependency detected ]
[  523.734990] 4.1.0-dbg-DEV #1676 Not tainted
[  523.739202] -------------------------------------------------------
[  523.745474] ss/18032 is trying to acquire lock:
[  523.750002]  (slock-AF_INET){+.-...}, at: [&lt;ffffffff81669d44&gt;] tcp_get_info+0x2c4/0x360
[  523.758129]
[  523.758129] but task is already holding lock:
[  523.763968]  (&amp;(&amp;hashinfo-&gt;ehash_locks[i])-&gt;rlock){+.-...}, at: [&lt;ffffffff816bcb75&gt;] inet_diag_dump_icsk+0x1d5/0x6c0
[  523.774661]
[  523.774661] which lock already depends on the new lock.
[  523.774661]
[  523.782850]
[  523.782850] the existing dependency chain (in reverse order) is:
[  523.790326]
-&gt; #1 (&amp;(&amp;hashinfo-&gt;ehash_locks[i])-&gt;rlock){+.-...}:
[  523.796599]        [&lt;ffffffff811126bb&gt;] lock_acquire+0xbb/0x270
[  523.802565]        [&lt;ffffffff816f5868&gt;] _raw_spin_lock+0x38/0x50
[  523.808628]        [&lt;ffffffff81665af8&gt;] __inet_hash_nolisten+0x78/0x110
[  523.815273]        [&lt;ffffffff816819db&gt;] tcp_v4_syn_recv_sock+0x24b/0x350
[  523.822067]        [&lt;ffffffff81684d41&gt;] tcp_check_req+0x3c1/0x500
[  523.828199]        [&lt;ffffffff81682d09&gt;] tcp_v4_do_rcv+0x239/0x3d0
[  523.834331]        [&lt;ffffffff816842fe&gt;] tcp_v4_rcv+0xa8e/0xc10
[  523.840202]        [&lt;ffffffff81658fa3&gt;] ip_local_deliver_finish+0x133/0x3e0
[  523.847214]        [&lt;ffffffff81659a9a&gt;] ip_local_deliver+0xaa/0xc0
[  523.853440]        [&lt;ffffffff816593b8&gt;] ip_rcv_finish+0x168/0x5c0
[  523.859624]        [&lt;ffffffff81659db7&gt;] ip_rcv+0x307/0x420

Lets use u64_sync infrastructure instead. As a bonus, 64bit
arches get optimized, as these are nop for them.

Fixes: 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info")
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>tcp: add tcpi_segs_in and tcpi_segs_out to tcp_info</title>
<updated>2015-05-22T03:25:21+00:00</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
<email>mleitner@redhat.com</email>
</author>
<published>2015-05-20T23:35:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2efd055c53c06b7e89c167c98069bab9afce7e59'/>
<id>urn:sha1:2efd055c53c06b7e89c167c98069bab9afce7e59</id>
<content type='text'>
This patch tracks the total number of inbound and outbound segments on a
TCP socket. One may use this number to have an idea on connection
quality when compared against the retransmissions.

RFC4898 named these : tcpEStatsPerfSegsIn and tcpEStatsPerfSegsOut

These are a 32bit field each and can be fetched both from TCP_INFO
getsockopt() if one has a handle on a TCP socket, or from inet_diag
netlink facility (iproute2/ss patch will follow)

Note that tp-&gt;segs_out was placed near tp-&gt;snd_nxt for good data
locality and minimal performance impact, while tp-&gt;segs_in was placed
near tp-&gt;bytes_received for the same reason.

Join work with Eric Dumazet.

Note that received SYN are accounted on the listener, but sent SYNACK
are not accounted.

Signed-off-by: Marcelo Ricardo Leitner &lt;mleitner@redhat.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>tcp: ensure epoll edge trigger wakeup when write queue is empty</title>
<updated>2015-05-21T22:52:47+00:00</updated>
<author>
<name>Jason Baron</name>
<email>jbaron@akamai.com</email>
</author>
<published>2015-05-20T15:52:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ce5ec440994b7b2b714633b516b9e0a4f6a98dfe'/>
<id>urn:sha1:ce5ec440994b7b2b714633b516b9e0a4f6a98dfe</id>
<content type='text'>
We currently rely on the setting of SOCK_NOSPACE in the write()
path to ensure that we wake up any epoll edge trigger waiters when
acks return to free space in the write queue. However, if we fail
to allocate even a single skb in the write queue, we could end up
waiting indefinitely.

Fix this by explicitly issuing a wakeup when we detect the condition
of an empty write queue and a return value of -EAGAIN. This allows
userspace to re-try as we expect this to be a temporary failure.

I've tested this approach by artificially making
sk_stream_alloc_skb() return NULL periodically. In that case,
epoll edge trigger waiters will hang indefinitely in epoll_wait()
without this patch.

Signed-off-by: Jason Baron &lt;jbaron@akamai.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: add a force_schedule argument to sk_stream_alloc_skb()</title>
<updated>2015-05-21T20:56:40+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-05-19T20:26:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=eb9344781a2f8381ed60cd9e662d9ced2d168ecb'/>
<id>urn:sha1:eb9344781a2f8381ed60cd9e662d9ced2d168ecb</id>
<content type='text'>
In commit 8e4d980ac215 ("tcp: fix behavior for epoll edge trigger")
we fixed a possible hang of TCP sockets under memory pressure,
by allowing sk_stream_alloc_skb() to use sk_forced_mem_schedule()
if no packet is in socket write queue.

It turns out there are other cases where we want to force memory
schedule :

tcp_fragment() &amp; tso_fragment() need to split a big TSO packet into
two smaller ones. If we block here because of TCP memory pressure,
we can effectively block TCP socket from sending new data.
If no further ACK is coming, this hang would be definitive, and socket
has no chance to effectively reduce its memory usage.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
