From: Eric Dumazet
Date: Wed, 22 Apr 2015 12:12:20 -0700
> On Wed, 2015-04-22 at 14:50 -0400, David Miller wrote:
>> From: Eric Dumazet
>> Date: Wed, 22 Apr 2015 11:39:27 -0700
>>
>> > Note that in the unlikely case skb can not be allocated,
>> > if an already transmitted packet is in the write
On Wed, 2015-04-22 at 14:50 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Wed, 22 Apr 2015 11:39:27 -0700
>
> > Note that in the unlikely case skb can not be allocated,
> > if an already transmitted packet is in the write queue, we also can OR
> > the FIN flag on it, and rely on normal
From: Eric Dumazet
Date: Wed, 22 Apr 2015 11:39:27 -0700
> Note that in the unlikely case skb can not be allocated,
> if an already transmitted packet is in the write queue, we also can OR
> the FIN flag on it, and rely on normal rtx to deliver this FIN later.
>
> I'll cook a patch when net-next
On Wed, 2015-04-22 at 14:15 -0400, David Miller wrote:
> Wrt. longer term solutions, I would even be OK at this point aborting
> the connection altogether if the skb allocation fails period. Not
> just if TIF_MEMDIE is set. That endless loop has been nothing but
> trouble.
Agreed.
Note that in
From: Eric Dumazet
Date: Tue, 21 Apr 2015 18:32:24 -0700
> From: Eric Dumazet
>
> Using sk_stream_alloc_skb() in tcp_send_fin() is dangerous in
> case a huge process is killed by OOM, and tcp_mem[2] is hit.
>
> To be able to free memory we need to make progress, so this
> patch allows FIN pack
From: Eric Dumazet
Using sk_stream_alloc_skb() in tcp_send_fin() is dangerous in
case a huge process is killed by OOM, and tcp_mem[2] is hit.
To be able to free memory we need to make progress, so this
patch allows FIN packets to not care about tcp_mem[2], if
skb allocation succeeded.
In a foll
