9.0-RC1 panic in tcp_input: negative winow.

[John Baldwin]

On Friday, October 28, 2011 1:46:07 am Pawel Jakub Dawidek wrote:
> On Fri, Oct 28, 2011 at 11:29:34AM +1100, Lawrence Stewart wrote:
> > On 10/26/11 22:53, John Baldwin wrote:
> > > The assertion would be triggered when the next packet arrives (as I said
> > > above).  Try modifying your debugging output to also log if the ACK is
> > > delayed.  I suspect it is not delayed until the last one.  (Pushing out 
an
> > > ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the 
case
> > > of an immediate ACK, rcv_nxt>  rcv_adv is only a transient condition all
> > > under a single lock invocation so never visible to other consumers of 
the
> > > protocol control block.)  If that is what you see, then that confirms 
what
> > > I guessed above and I will likely just remove the assertion in 
tcp_input()
> > > and patch the timewait code to handle this case.
> > >
> > 
> > Pawel, have you been able to confirm John's hypothesis? [...]
> 
> Yeah, sorry. I moved the debug to the points where we drop the t_inpcb
> lock and I still see rcv_nxt being greater than rcv_adv:
> 
> 	tcp_do_segment:2970 negative window: tp 0xfffffe00685ee3d0 rcv_nxt 
1312878324 rcv_adv 1312878187

Yes, I still expect this.  What I want to see is if 'delack' is always true in 
this case.

> This is just before the INP_WUNLOCK(tp->t_inpcb) under 'check_delack'
> label. I see this a lot (it was logged 545 times for 11 different tp
> pointers during 24h period).
> 
> 	tcp_do_segment:3009 negative window: tp 0xfffffe005cfc6000 rcv_nxt 
1442546453 rcv_adv 1442545722
> 
> This is just before calling tcp_output(). This one was logged 65 times
> for 3 different tp pointers.
> I placed a debug also after tcp_output() call, but it is not logged, so
> once we return from tcp_output() everything is fine.

That is consistent with what I expect then, since in the delack case,
tcp_output() isn't called.

-- 
John Baldwin