On Mon, Oct 21, 2019 at 8:04 PM Subash Abhinov Kasiviswanathan
wrote:
>
> > Interesting! As tcp_input.c summarizes, "packets_out is
> > SND.NXT-SND.UNA counted in packets". In the normal operation of a
> > socket, tp->packets_out should not be 0 if any of those other fields
> > are non-zero.
> >
>
Interesting! As tcp_input.c summarizes, "packets_out is
SND.NXT-SND.UNA counted in packets". In the normal operation of a
socket, tp->packets_out should not be 0 if any of those other fields
are non-zero.
The tcp_write_queue_purge() function sets packets_out to 0:
https://git.kernel.org/pub/scm
On Mon, Oct 21, 2019 at 10:42 AM Subash Abhinov Kasiviswanathan
wrote:
>
> > Please give us a pointer to the exact git tree and sha1.
> >
> > I do not analyze TCP stack problems without an exact starting point,
> > or at least a crystal ball, which I do not have.
>
> Hi Eric
>
> We are at this com
Please give us a pointer to the exact git tree and sha1.
I do not analyze TCP stack problems without an exact starting point,
or at least a crystal ball, which I do not have.
Hi Eric
We are at this commit - Merge 4.19.75 into android-4.19-q.
https://android.googlesource.com/kernel/common/+/cf
On 10/20/19 1:25 PM, Subash Abhinov Kasiviswanathan wrote:
> We are seeing a crash in the TCP ACK codepath often in our regression
> racks with an ARM64 device with 4.19 based kernel.
>
Please give us a pointer to the exact git tree and sha1.
I do not analyze TCP stack problems without an exa
On Sun, Oct 20, 2019 at 10:45 PM Subash Abhinov Kasiviswanathan
wrote:
>
> > FIN-WAIT1 just means the local application has called close() or
> > shutdown() to shut down the sending direction of the socket, and the
> > local TCP stack has sent a FIN, and is waiting to receive a FIN and an
> > ACK
FIN-WAIT1 just means the local application has called close() or
shutdown() to shut down the sending direction of the socket, and the
local TCP stack has sent a FIN, and is waiting to receive a FIN and an
ACK from the other side (in either order, or simultaneously). The
ASCII art state transition
On Sun, Oct 20, 2019 at 7:15 PM Subash Abhinov Kasiviswanathan
wrote:
>
> > Hmm. Random related thought while searching for a possible cause: I
> > wonder if tcp_write_queue_purge() should clear tp->highest_sack (and
> > possibly tp->sacked_out)? The tcp_write_queue_purge() code is careful
> > to
Hmm. Random related thought while searching for a possible cause: I
wonder if tcp_write_queue_purge() should clear tp->highest_sack (and
possibly tp->sacked_out)? The tcp_write_queue_purge() code is careful
to call tcp_clear_all_retrans_hints(tcp_sk(sk)) and I would imagine
that similar considera
tcp_write_queue_purgeOn Sun, Oct 20, 2019 at 4:25 PM Subash Abhinov
Kasiviswanathan wrote:
>
> We are seeing a crash in the TCP ACK codepath often in our regression
> racks with an ARM64 device with 4.19 based kernel.
>
> It appears that the tp->highest_ack is invalid when being accessed when
> a
10 matches
Mail list logo