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).
-Andi
-
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/