Date: Thu, 14 Dec 2017 18:49:24 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: John Baldwin <jhb@FreeBSD.org>, Konstantin Belousov <kostikbel@gmail.com>, Conrad Meyer <cem@FreeBSD.org>, Alexey Dokuchaev <danfe@freebsd.org> Cc: 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: <5A326544.1030706@grosbein.net> In-Reply-To: <5A3261BD.5050404@grosbein.net> 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> <e2c426c3-41ed-2dd8-c5d4-15c60d8f7303@FreeBSD.org> <5A3261BD.5050404@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14.12.2017 18:34, 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 <nfssvc_nfsd>: >>> 1152 nfs_nfsdserv.o <nfsrvd_lockt>: >>> 1128 nfs_nfsdserv.o <nfsrvd_lock>: >>> 952 nfs_nfsdserv.o <nfsrvd_rename>: >>> 664 nfs_nfsdserv.o <nfsrvd_open>: >>> 640 nfs_nfsdserv.o <nfsrvd_link>: >>> 624 nfs_nfsdserv.o <nfsrvd_create>: >>> 608 nfs_nfsdserv.o <nfsrvd_mknod>: >>> 600 nfs_clvfsops.o <nfs_mount>: >> >> 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 Final post in the thread describes amd64 crash with kstack_pages=5 due to 75 frames: https://lists.freebsd.org/pipermail/freebsd-stable/2017-July/087477.html He increased kstack_pages upto 6 and stopped posting, as it obviously helped him finally. By the way, I finally realised why I do not have KVA problems with my i386 hosts: I run all of them (no PAE) with options KVA_PAGES=512 (2GB) at least and even 768 (3GB) in case of ZFS instead of default 256 (1GB) to make it stable. Tell me more of untweaked FreeBSD stability...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A326544.1030706>