summaryrefslogtreecommitdiff
path: root/samples/kfifo
diff options
context:
space:
mode:
authorEric Dumazet <edumazet@google.com>2015-04-23 10:42:39 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2015-05-06 21:56:20 +0200
commitbc9f0ea1c736358f2db263ee2afe5af5a9dfcf2a (patch)
tree4b8a0e6f0a2152205e73cd6aa91191d3eb32b0e6 /samples/kfifo
parentaac9fda375bbe75e0b8c033874af25e0f7f5a3a4 (diff)
downloadlwn-bc9f0ea1c736358f2db263ee2afe5af5a9dfcf2a.tar.gz
lwn-bc9f0ea1c736358f2db263ee2afe5af5a9dfcf2a.zip
tcp: avoid looping in tcp_send_fin()
[ Upstream commit 845704a535e9b3c76448f52af1b70e4422ea03fd ] Presence of an unbound loop in tcp_send_fin() had always been hard to explain when analyzing crash dumps involving gigantic dying processes with millions of sockets. Lets try a different strategy : In case of memory pressure, try to add the FIN flag to last packet in write queue, even if packet was already sent. TCP stack will be able to deliver this FIN after a timeout event. Note that this FIN being delivered by a retransmit, it also carries a Push flag given our current implementation. By checking sk_under_memory_pressure(), we anticipate that cooking many FIN packets might deplete tcp memory. In the case we could not allocate a packet, even with __GFP_WAIT allocation, then not sending a FIN seems quite reasonable if it allows to get rid of this socket, free memory, and not block the process from eventually doing other useful work. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'samples/kfifo')
0 files changed, 0 insertions, 0 deletions