22.07.2017 12:42, Don Lewis wrote:> The double fault is a pretty good indication that you overflowed the > kernel stack. Having ~40 frames on the stack when the fault happened is > consistent with that. > > It looks like you are trying to execute a program from an NFS file > system that is exported by the same host. This isn't exactly optimal > ... > > Your best bet for a quick workaround for the stack overflow would be to > rebuild the kernel with a larger value of KSTACK_PAGES. You can find > teh default in /usr/src/sys/<arch>/conf/NOTES. > > It would probably be a good idea to compute the differences in the stack > pointer values between adjacent stack frames to see of any of them are > consuming an excessive amount of stack space.Also, there is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219476 Eugene Grosbein
On Sat, Jul 22, 2017 at 12:51:01PM +0700, Eugene Grosbein wrote:> Also, there is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219476I strongly disagree with the idea of increasing the default kernel stack size, it will cause systematic problems for all users instead of current state where some workloads are problematic. Finding contig KVA ranges for larger stacks on KVA-starved architectures is not going to work. The real solution is to move allocations from stack to heap, one by one. You claimed that vm/vm_object.o consumes 1.5K of stack, can you show the ddb backtrace of this situation ?