Date: Mon, 11 Dec 2017 11:12:36 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Eugene Grosbein <eugen@grosbein.net> Cc: Michael Tuexen <tuexen@fh-muenster.de>, Konstantin Belousov <kostikbel@gmail.com>, Conrad Meyer <cem@freebsd.org>, 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: <201712111912.vBBJCaFO082664@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <5A2ED61C.5060209@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 12.12.2017 1:52, Michael Tuexen wrote: > > > Not sure about IPSEC and ZFS. But I was NOT able to reproduce the issue by just using > > an SCTP association on a 32-bit VM using FreeBSD 11.1. So right now I don't know what > > is wrong and therefore what could be fixed... > > You just got lucky. Kernel stack abuse by multiple parts of FreeBSD kernel it matter of fact. > But it is not like you always get a panic because sometimes network traffic > is passed through NETISR queues to reduce stack usage and sometimes it is not, > depending on several run-time factors. You may find it stable with one NIC driver > and crashing with another even just because of different stack usage. > I agree with that, there is and has been a kernel stack space issue on i386 for some time. But lets all agree just cranking the size of the kernel stack up is a poor long term solution as the larger you crank this the less number of processes you can have due to limited KVA. So, first off, ZFS, well that is fairly well documented to not be a good idea on i386, and well documented to be a bad idea with only 4G of memory. So make sure that this stays documented, along with what one should tweak to make it work, most of which is already in https://wiki.freebsd.org/ZFSTuningGuide#i386 someone please verify that you really need to increase KSTACK, cause last time I played with ZFS on i386 I just used that tuning guide and all was happy. If it is found necessary to add KSTACK pages, document that above and include in that document the side effects of doing so. As far as IPSEC and SCTP, maybe someone can take a once over through the code looking for stack abuse with local variables that really should be malloced, passing large stuff in function call arguments rather than a pointer. Possibly even doing some dtrace to find out how close we get to the limits. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201712111912.vBBJCaFO082664>