On 10/06/16 at 09:51P, Julien Charbon wrote: > > Hi Hiren, > > On 10/6/16 9:44 AM, hiren panchasara wrote: > > On 10/06/16 at 09:28P, Julien Charbon wrote: > >> On 9/28/16 1:59 PM, Slawa Olhovchenkov wrote: > >>> On Wed, Sep 28, 2016 at 12:06:47PM +0200, Julien Charbon wrote: > >>>> <SNIP> > >>>> I am still trying to reproduce your issue, without success so far. > >> > >> Thanks for Slawa effort and multiple debug report we start seeing the > >> bottom of this issue and it seems to be a generic one. The most useful > >> report being: > >> > >> panic: tcp_detach: INP_TIMEWAIT && INP_DROPPED && tp != NULL > > > > I know there are multiple and probably related problems being > > discussed here but what about the one mentioned in subject of this > > thread? > > Apologies if I've missed something conclusive in one of the replies of > > this thread about that issue. > > This issue can lead the machine being stuck on high network load, by > double freeing an inp, you can corrupt/leak an inp lock, and the network > stack can wait definitely on this inp lock to be released. You get this > assert only with INVARIANTS defined. > > Of usual, we can have more than one issue here, but this > INP_TIMEWAI|INP_DROPPED issue need to be fixed anyway.
Thanks for the explanation, Julien. Cheers, Hiren
pgpsLxxVbSK2k.pgp
Description: PGP signature
