Messages in this thread | | | Date | Sun, 25 Oct 1998 16:46:12 -0800 | From | "David S. Miller" <> | Subject | Re: [patch] my latest oom stuff - another thing. |
| |
From: Andi Kleen <ak@muc.de> Date: 25 Oct 1998 15:06:27 +0100
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/
| |