[lkml]   [1998]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] my latest oom stuff - another thing.
On Mon, Oct 26, 1998 at 01:46:12AM +0100, David S. Miller wrote:
> From: Andi Kleen <>
> 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.

True, but for tcp_send_active_reset this is not the case - if we don't send
the RST now it will be triggered once the other end retransmits (if he doesn't
that's fine too). I propose to remove the loop there and just try to
allocate once.

> 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.

How about extending the standard socket timer (ipv4/timer.c) for this ?
It would just need a new timer type "TIME_RETRY" and a protocol entry
point to call in this case. Then when the initial FIN allocation fails
just start a timer for 1s (like e.g. the retransmit handler does when he
gets an locked socket).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:45    [W:0.058 / U:6.512 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site