From owner-svn-src-all@freebsd.org Thu Dec 14 11:51:58 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 89D02EA122F; Thu, 14 Dec 2017 11:51:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 31804808BE; Thu, 14 Dec 2017 11:51:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id vBEBpnch094111 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Dec 2017 13:51:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vBEBpnch094111 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vBEBpnDm094110; Thu, 14 Dec 2017 13:51:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Dec 2017 13:51:49 +0200 From: Konstantin Belousov To: Eugene Grosbein Cc: John Baldwin , Conrad Meyer , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326758 - in head/sys/i386: conf include Message-ID: <20171214115149.GC2272@kib.kiev.ua> References: <201712110432.vBB4WbnE021090@repo.freebsd.org> <20171211091943.GF2272@kib.kiev.ua> <5A2E5D44.9030904@grosbein.net> <4a9c76c9-8063-9420-b198-14487b089840@FreeBSD.org> <5A30378A.3040609@grosbein.net> <5A3261BD.5050404@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A3261BD.5050404@grosbein.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Thu, 14 Dec 2017 11:51:58 -0000 On Thu, Dec 14, 2017 at 06:34:21PM +0700, Eugene Grosbein wrote: > On 13.12.2017 04:55, John Baldwin wrote: > > On 12/12/17 3:09 PM, Eugene Grosbein wrote: > >> On 13.12.2017 02:32, John Baldwin wrote: > >> > >>> Certainly for MIPS I have found that compiling with clang > >>> instead of gcc for mips64 gives a kernel that panics for stack overflow for any > >>> use of NFS. It might be that this is due to something MIPS-specific, but it > >>> might be worthwhile retesting with kstack_pages=2 and building the kernel > >>> with CROSS_TOOLCHAIN=i386-gcc after installing the appropriate package. > >> > >> You may want to check NFS code that uses stack heavily. > >> Here are numbers for i386 (bytes-on-stack, module, what function): > >> > >> 1344 nfs_nfsdport.o : > >> 1152 nfs_nfsdserv.o : > >> 1128 nfs_nfsdserv.o : > >> 952 nfs_nfsdserv.o : > >> 664 nfs_nfsdserv.o : > >> 640 nfs_nfsdserv.o : > >> 624 nfs_nfsdserv.o : > >> 608 nfs_nfsdserv.o : > >> 600 nfs_clvfsops.o : > > > > My point is that you should compare gcc with clang as 10.x switched to > > clang and that may be a factor in the stack overflows beginning with 10.x. > > I think thats's NFS code who is guilty. You can see example of amd64 (sic!) kstack exhaustion > due to 40+ frames deep call chain here: > > https://lists.freebsd.org/pipermail/freebsd-stable/2017-July/087429.html Yes, NFS crosses network/VFS and often VM boundaries, so each subsystem adds its usual stack use footprint to the overall picture. NFS reconnect is especially hard in this regard, and in case the direct dispatch is triggered (in this case over loopback) machine has no chance. The backtrace you cited just reinforces the point that the i386 commit is wrong. It breaks the workload we aims as the main FreeBSD target, which is generic-purpose Unix workstation or server. The commit tries to make defaults fit for specific appliance load of router with IPSEC or ZFS on i386, which require extensive tuning on i386 anyway. Worse, as you prove above, the commit in fact does not fix the issues, it only papers over them and move easily triggered faults from one configuration to another.