From owner-svn-src-all@freebsd.org Tue Dec 12 17:01:43 2017 Return-Path: Delivered-To: svn-src-all@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 BE805E9F037; Tue, 12 Dec 2017 17:01:43 +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 425926594F; Tue, 12 Dec 2017 17:01:42 +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 vBCH15kd087154; Tue, 12 Dec 2017 09:01:05 -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 vBCH153d087153; Tue, 12 Dec 2017 09:01:05 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201712121701.vBCH153d087153@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r326758 - in head/sys/i386: conf include In-Reply-To: <5A2FFFFB.4030501@grosbein.net> To: Eugene Grosbein Date: Tue, 12 Dec 2017 09:01:05 -0800 (PST) CC: rgrimes@freebsd.org, 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-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 17:01:43 -0000 [ Charset windows-1252 unsupported, converting... ] > 12.12.2017 22:30, Rodney W. Grimes: > > >>> Now I run FreeBSD 11/i386 as my home router with IPSEC and torrent > >>> client, and I run several virtualized routers with IPSEC tunnels, > >>> jabber and mail server, squid and ZFS for src/obj/ports compression > >>> and they all easily crash unless kern.kstack_pages raised upto 4. Same > >>> for some other my i386 installations having IPSEC tunnels. > >> > >> IPSEC definitely used to wwith with kstack_pages=2 since I ran that way > >> for a number of years. I haven't used IPSEC since I upgraded from > >> FreeBSD 8.x to 10.x a while back, so it could be broken now. > > > > I think this comes as a regression in 10.x or perhaps later. So that > > atleast narrows down what has triggered the need for more kernel stack > > space. > > Once again, that's not about IPSEC only that, indeed, had this kind of "regression" I didnt mean to make it sound like it was IPSEC only, I simply meant to say that in general we have a kstack use regression that appears to have started after 10.x. I hope this clarifies my point. > with overhaul of its code between 11.0 and 11.1 releases with r315514. > It was already polished in stable/11 with later r319118 plus there is > https://reviews.freebsd.org/D9721 that introduces new > sysctl net.inet.ipsec.use_netisr=1 > to convert long path of direct function calls requiring large stack to > queuing of outgoing to-be-encrypted traffic using NETISR > at cost of some performance penalty when enabled. > > But many other parts of kernel think it's OK to allocate big arrays or > structures on stack. We should probably start looking for those, something someone who is offerring help but doesnt know what they might be good at, but can read C code. They could be utililized t simply scan through the code looking for this type of thing and bring it to the attention of a area of expertise commiter. -- Rod Grimes rgrimes@freebsd.org