On 02/14/2019 05:08 PM, Eric Dumazet wrote:
>
>
> On 02/14/2019 03:54 PM, 배석진 wrote:
>>> I do not believe this patch is needed.
>>>
>>> You probably hit another more serious bug, but since you do not post the
>>> full stack trace
>>> it is hard to help.
>>>
>>> Are you using vti tunnel ?
>>
>> there's no working logs of vpn/vti/tun on platform or kernel history.
>> and callstack has no functions about that.
>> it looks like simple ipv4 usage.
>>
>> attaching full dump info.
>> no additional bug or warning on entire kernel history.
>> anything about tun or kasan even onther.
>>
>> thanks.
>>
>>
>> <4>[60392.948306] I[1: ksoftirqd/1: 19] ------------[ cut here
>> ]------------
>> <0>[60392.948334] I[1: ksoftirqd/1: 19] kernel BUG at
>> net/ipv4/tcp_ipv4.c:519!
>
> What the code looks like at line 519 of net/ipv4/tcp_ipv4.c ?
>
> This is not a pristine kernel, anything could be wrong, you might have missed
> some critical backports.
The current code checks if icsk->icsk_backoff is not zero, so it looks like we
have to move
some code like this.
It looks a silly bug to have no packet in write/rtx queues, and a non zero
icsk_backoff.
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index
2079145a3b7c5f498af429c9a8289342e4421fca..cf3c5095c10e8e7e56621beae2f93c93de184489
100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2528,6 +2528,7 @@ void tcp_write_queue_purge(struct sock *sk)
sk_mem_reclaim(sk);
tcp_clear_all_retrans_hints(tcp_sk(sk));
tcp_sk(sk)->packets_out = 0;
+ inet_csk(sk)->icsk_backoff = 0;
}
int tcp_disconnect(struct sock *sk, int flags)
@@ -2576,7 +2577,6 @@ int tcp_disconnect(struct sock *sk, int flags)
tp->write_seq += tp->max_window + 2;
if (tp->write_seq == 0)
tp->write_seq = 1;
- icsk->icsk_backoff = 0;
tp->snd_cwnd = 2;
icsk->icsk_probes_out = 0;
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
