Date: Tue, 12 Dec 2017 02:33:22 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: rgrimes@freebsd.org 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: <5A2EDD82.1040404@grosbein.net> In-Reply-To: <201712111912.vBBJCaFO082664@pdx.rh.CN85.dnsmgr.net> References: <201712111912.vBBJCaFO082664@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
12.12.2017 2:12, Rodney W. Grimes 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. OTOH, it seems to be totally unrealistic to hope the problem can be solved in feasible future as such crashes were not fixed for several *years* (at least since 10.x era). > 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. That's just incorrect. With 4 kstack pages, you could utilize ZFS for compressed src/obj/ports with virtualized FreeBSD 9 and 1GB memory using following loader.conf settings: zfs_load="YES" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="8M" vfs.zfs.prefetch_disable="1" And that was pretty stable as ARC was really limited. This was broken in 10.x and later so that ARC grows order of magnitude (x10) larger, though. > 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. That's not just ZFS, IPSEC or SCTP. It spreads all over kernel parts: wifi subsystem and drivers, libkern/zlib, crypto, scsi/cam/da/ada drivers, vm subsystem itself, NFS etc. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219476
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A2EDD82.1040404>