> 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
> 2079145a3b7
> > <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 c
> 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 ab
Dear all,
https://www.mail-archive.com/netdev@vger.kernel.org/msg256527.html
as we concerned before at above mail thread,
we faced a problem cased by not removed socket.
(from now, 'the socket' means the socket alloced at 0xFFC0051E5E00)
#1. the socket is state in TIME_WAIT1. maybe it's pr
> What harm is caused by these stale sessions? I thought that was the
> intended behaviour.
>
our system stability guys concern about this.
when its count grows up too much, whether it can be harm to system or not.
> If you look at the original design discussions that led to the
> SOCK_DESTROY an
>> we saw hundreds of not closed tcp session with FIN_WAIT1 and LAST_ACK.
>
> These sessions should have a timer, and eventually disappear.
FIN_WAIT2 and TIME_WAIT have a timer.
but FIN_WAIT1 and LAST_ACK are have too?
> Do you have a test to demonstrate the issue ?
>
> I know Lorenzo wrote te
e the fin-ack frequently.
thanks,
- Original Message -
Sender : 배석진 Staff Engineer/System개발2그룹(무선)/삼성전자
Date : 2018-11-23 16:22 (GMT+9)
Title : Suggesting patch for tcp_close
Dear all,
This is Soukin Bae working on Samsung Elec. Mobile Division.
we have a problem wit
Dear all,
This is Soukin Bae working on Samsung Elec. Mobile Division.
we have a problem with tcp closing.
in shortly,
1. on 4-way handshking to close session
2. if ack pkt is not arrived from opposite side
3. then session can't be closed forever
in mobile device, condition 2 can be happend i
> Also we might note that flow dissector itself is buggy as
> found by Soukjin Bae ( https://patchwork.ozlabs.org/patch/994601/ )
>
> I will send a v2 of his patch with a different changelog.
>
> Defrag is fixed [1] but the bug in flow dissector is adding
> extra work and hash inconsistencies.
>
>On 11/08/2018 04:42 PM, 배석진 wrote:
>> Thanks for testing.
>>>
>>> This is not a pristine net-next tree, this dump seems unrelated to the
>>>patch ?
>>
>>
>> yes, looks like that.
>> but only when using your patch, panic came. even r
>Thanks for testing.
>
>This is not a pristine net-next tree, this dump seems unrelated to the patch ?
yes, looks like that.
but only when using your patch, panic came. even right after packet recieving..
without that, there's no problem except defrag issue. it's odd.. :p
I couldn't more debuggin
>- Original Message -
>Sender : Eric Dumazet
>Date : 2018-11-08 15:13 (GMT+9)
>Title : Re: (2) (2) [Kernel][NET] Bug report on packet defragmenting
>
>On 11/07/2018 08:26 PM, Eric Dumazet wrote:
>>
>>
>> On 11/07/2018 08:10 PM, 배석진 wr
> - Original Message -
> Sender : Eric Dumazet
> Date : 2018-11-08 12:57 (GMT+9)
> Title : Re: (2) [Kernel][NET] Bug report on packet defragmenting
>
> On 11/07/2018 07:24 PM, Eric Dumazet wrote:
>
> > Sure, it is better if RPS is smarter, but if there is a bug in IPv6 defrag
- Original Message -
Sender : Eric Dumazet
Date : 2018-11-08 10:44 (GMT+9)
Title : Re: [Kernel][NET] Bug report on packet defragmenting
> On 11/07/2018 05:29 PM, 배석진 wrote:
>
> > If ipv6_defrag hook is not excuted simultaneously, then it's ok.
> &g
Hello,
This is bae working on Samsung Elec.
We got the problem that fragmented SIP packet couldn't be deliverd to user
layer.
And found that they were stoled at HOOK function, ipv6_defrag.
In condition with SMP and RPS.
After first fragmented packet, they have no further network header except i
req = inet_reqsk(sk);
- Original Message -
Sender : Eric Dumazet
Date : 2018-02-07 13:31 (GMT+9)
Title : Re: [Android][Kernel][TCP/IP] report of packet discarding during tcp
handshaking
On Wed, 2018-02-07 at 11:16 +0900, 배석진 wrote:
> Hello,
> this is bae working on samsu
Hello,
this is bae working on samsung elec.
we have a problem that packet discarded during 3-way handshaking on TCP.
already looks like that Mr Dumazet try to fix the similar issue on this patch,
https://android.googlesource.com/kernel/common/+/5e0724d027f0548511a2165a209572d48fe7a4c8
but we
17 matches
Mail list logo
