From owner-svn-src-head@freebsd.org Tue Dec 12 20:43:50 2017 Return-Path: Delivered-To: svn-src-head@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 0C695E846F5; Tue, 12 Dec 2017 20:43:50 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C78D572423; Tue, 12 Dec 2017 20:43:49 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBCKhI6I088372; Tue, 12 Dec 2017 12:43:18 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBCKhIsD088371; Tue, 12 Dec 2017 12:43:18 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201712122043.vBCKhIsD088371@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r326758 - in head/sys/i386: conf include In-Reply-To: <5A302DF7.1090706@grosbein.net> To: Eugene Grosbein Date: Tue, 12 Dec 2017 12:43:18 -0800 (PST) CC: rgrimes@freebsd.org, Andriy Gapon , Don Lewis , Alexey Dokuchaev , Konstantin Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Conrad Meyer Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 13 Dec 2017 01:20:54 +0000 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:43:50 -0000 > On 13.12.2017 00:32, Rodney W. Grimes wrote: > > >> I am not sure if there are tools that can analyze stack requirements for > >> possible call chains rather than individual functions. > > > > Call graphs can be used to find deep chains. Combine the above > > with a call graph and we should be able to come up with some > > data. > > > > This also sounds like a good caniate for GSOC, creation > > of a call graph with static analysis of local variable size + > > call frame size requirements as a O(1) stack space estimator. > > "Longitude" of call chain greatly depends of run-time system configuration. > For example, application sendto() call can result in variable number > of system calls performing IPSEC transformations (ESP, AH, IPCOMP) > then custom PFIL processing then multiple NETGRAPH calls then complex > WiFi stack operations and each of such calls can result in kernel stack exhaustion. That was why I expressed it as an O(1) estimator. Attempting to do this more complex problem you describe would probably best be left to dtrace and some coverage metrics to make sure we hit most of the paths. At this time I don't think we need that. I think what you did with your very quick turn around of the simple static data is probably going to lead to rapid closure of the problem, or at least greatly reduce it. Or are you thinking we have something that is so deep even if it only uses 32 bytes of stack we are going to run ourselfs out of kstack under some work loads? I hope not. -- Rod Grimes rgrimes@freebsd.org