From owner-freebsd-stable@freebsd.org Thu Oct 13 14:38:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A56ECC10D19 for ; Thu, 13 Oct 2016 14:38:36 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63D608B3; Thu, 13 Oct 2016 14:38:36 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1buh9N-000EyH-JC; Thu, 13 Oct 2016 17:38:25 +0300 Date: Thu, 13 Oct 2016 17:38:25 +0300 From: Slawa Olhovchenkov To: Julien Charbon Cc: Konstantin Belousov , freebsd-stable@FreeBSD.org, hiren panchasara Subject: Re: 11.0 stuck on high network load Message-ID: <20161013143825.GK57714@zxy.spb.ru> References: <20161012092945.GB57714@zxy.spb.ru> <4b0d4b58-6d13-3cd5-6991-27163f27acca@freebsd.org> <20161012095233.GC57714@zxy.spb.ru> <20161012121322.GB57876@zxy.spb.ru> <62d8861c-673e-6d86-e96e-751399e505e5@freebsd.org> <20161012130103.GD57714@zxy.spb.ru> <20161012154229.GC57876@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 14:38:36 -0000 On Thu, Oct 13, 2016 at 01:56:21PM +0200, Julien Charbon wrote: > >> Something like: > > > > Yes, thanks! > > Proposed changes added in the review: > > https://reviews.freebsd.org/D8211 > > tell me when you have three days without issue with this change. > > >> tcp_detach() { > >> > >> ... > >> if (inp->inp_flags & INP_TIMEWAIT) { > >> > >> ... > >> if (inp->inp_flags & INP_DROPPED) { > >> > >> in_pcbdetach(inp); > >> if (__predict_true(tp == NULL)) { > >> in_pcbfree(inp); > >> } else { > >> #ifdef INVARIANTS > >> panic("tcp_detach: tp != NULL, That's not good because 'blah'\n"); > >> #else > >> log(LOG_ERR, "tcp_detach: tp != NULL, That's not good because > >> 'blah'\n"); > > > > May be some more info in log can help to detect root cause of issuse? > > I am don't know what info, may be flags or number of references? > > For this kind of issue, the useful part is the stacktrace. INVARIANT Like this? #ifdef KDB kdb_backtrace(); #endif as found in sys/netgraph/ng_base.c > will give you that trace in the core, and without INVARIANT then it is > better to use dtrace: > > $ cat tcp-twstart-dropped.d > fbt::tcp_twstart:entry > /args[0]->t_inpcb->inp_flags & 0x04000000/ > { > stack(); > printf("INP_DROPPED in tcp_twstart: %x", args[0]->t_inpcb->inp_flags); > } Same code may be insert there too, IMHO. > -- > Julien > >