tcp: avoid looping in tcp_send_fin()
authorEric Dumazet <edumazet@google.com>
Thu, 23 Apr 2015 17:42:39 +0000 (10:42 -0700)
committerBen Hutchings <ben@decadent.org.uk>
Sat, 9 May 2015 22:16:40 +0000 (23:16 +0100)
commit82241580d7734af2207ad0bb1720904f569dac3a
tree24508be6be29482ccb4a6203b2322b6d9c940dc1
parentfccb908d23fbae3e941e9294590dd94de6b1d822
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>
[bwh: Backported to 3.2:
 - Drop inapplicable change to sk_forced_wmem_schedule()
 - s/sk_under_memory_pressure(sk)/tcp_memory_pressure/]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
net/ipv4/tcp_output.c