Date: Tue, 23 May 2017 19:35:34 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219476] [i386] 11.1-PRERELEASE double panics due to low kern.kstack_pages default Message-ID: <bug-219476-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219476 Bug ID: 219476 Summary: [i386] 11.1-PRERELEASE double panics due to low kern.kstack_pages default Product: Base System Version: 11.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: eugen@freebsd.org stable/11 got lots of kernel level code that abuses small default stack of i386 kernel threads: ZFS, IPSEC, SCTP, device drivers etc. Overflow of kernel stack produces "double fault" panics. kern.kstack_pages is loader tunnable now for i386. The system should be stable out of the box, so we should increase default for kern.kstack_pages. Loader tunnable can serve users of i386 systems that are unhappy with new default, they can decrease it with /boot/loader.conf Some examples: * sys/netinet/sctp_pcb.c, function sctp_load_addresses_from_init() allocates 2184 bytes on stack (disassemble: sub $0x888,%esp); * sys/netinet/sctp_auth.c: sctp_auth_get_cookie_params(): 1592 bytes on stack; * src/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c: ar9300_eeprom_restore_internal_address(): 2092 bytes on stack; * sys/contrib/dev/ath/ath_hal/ar9300/ar9300_paprd.c: create_pa_curve(): 1416 bytes; * sys/libkern/zlib.c: huft_build(): 1420 bytes; And so on. Here is "top-list" for my home router custom kernel (1GB RAM, no swap): Bytes-on-stack In-module 2184 sctp_pcb.o 2092 ar9300_eeprom.o 2080 kern_linker.o 1664 cryptosoft.o 1592 sctp_auth.o 1536 glxsb_hash.o 1420 zlib.o 1416 ar9300_paprd.o 1352 scsi_da.o 1344 nfs_nfsdport.o 1328 vm_object.o 1312 fortuna.o 1232 cam_periph.o 1224 zlib.o 1192 cam_xpt.o 1192 ata_da.o 1184 cam_xpt.o 1168 ata_da.o 1160 sctp_output.o Some of "network hot path" subroutines not shown here do abuse kernel stack too, for example SHA256_Transform() from sys/crypto/sha2/sha256c.c that may be actively used with IPSEC processing. ae@'s https://reviews.freebsd.org/D10869 deals with IPSEC in part and helps in my case, at least while there is no ZFS involved. However, it is impossible to perform similar cleanup for each and every kernel subsystem in near future and double panics with current defaults are bad too. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219476-8>