On Wed, Oct 12, 2016 at 02:06:59PM +0200, Julien Charbon wrote:

> >>>>> sofree() call tcp_usr_detach() and in tcp_usr_detach() we have
> >>>>> unexpected INP_TIMEWAIT.
> >>>>
> >>>>  I see, thus just for the context:  The TCP stack in sys/dev/cxgb* is a
> >>>> TOE (TCP Offload Engine?) TCP stack for Chelsio NICs, it is a
> >>>> separate/side TCP stack that is used only with TCP_OFFLOAD option.
> >>>>
> >>>>  This TOE TCP stack actually has its own set of detach()/input()
> >>>> functions and seems to check INP_DROPPED flag properly.  I guess @np
> >>>> check fixes in socket TCP stack and decides which one can also impact
> >>>> the Chelsio TOE TCP stack.  Some bugs are only in socket TCP stack, some
> >>>> are only in TOE TCP stack.
> >>>
> >>> I am fear about other direction -- setting INP_TIMEWAIT in Chelsio TOE
> >>> TCP stack and impact this to
> >>> tcp_timer_2msl()/tcp_close()/sofree()/tcp_usr_detach() path.
> >>
> >>  I see, I expect no problem on this side as tcp_timer_2msl() checks the
> >> INP_TIMEWAIT flag and do not call tcp_close() if set.
> > 
> > I am about case when at time of first INP_WUNLOCK() tcp_timer_2msl()
> > don't see INP_TIMEWAIT, call tcp_close(), tcp_close() do INP_WUNLOCK()
> > and now Chelsio TOE take INP_WLOCK, do tcp_twstart() and set
> > INP_TIMEWAIT. After this tcp_timer_2msl resume and have unexpected
> > INP_TIMEWAIT in tcp_usr_detach().
>  Sure, basically the same bug that in classic TCP stack.  If you think
> it can happen, send an email describing that to np@ and he will check
> and fix that.  He is a TOE TCP stack expert and I am not.  In all cases,
> if this issue is possible in TOE TCP stack context, the patch will be
> straightforward:  If the INP_DROPPED flag is set do not call tcp_twstart().
>  The current patch focuses only on the classic TCP stack.

May be current workaround (with logging) in tcp_usr_detach() is good
solutuion for preventing system lockout by similar bugs?

freebsd-stable@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to