I forgot, there is another TCP case too where it might loop endlessly:
tcp_send_fin():
...
Fixing it here is harder, because when the FIN is not put into the retransmit
queue it menas that data will be lost (it is the same dilemma as Ingo has in
his raid code)
Yes, think many times before just wholesale removing this retry loop,
because there is no sure way to safely sleep on some other event (to
my knowledge) in this situation, and this is a "must not fail" packet
send. It has to go out one way or another.
My observation comes from the fact that there is no place to "wait for
an event". Such a "wait_for_tcp_memory()" type scheme would work for
the cases where the failed allocation is due to socket buffer
overcommit, incoming acks will remove retransmit queue buffers and
wake this guy up. But if it is due to a true "kernel out of memory"
allocation failure, and the retransmit queue is empty (ie. nothing
else is happening right now on this connection except this FIN) then
there will be no external event to wake up the socket and it has the
chance of sleeping forever.
I'll go over all of this and see what I can make of it as I implement
the sendfile() TCP bits...
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/