On Thu, Dec 14, 2017 at 06:34:21PM +0700, 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

Yes, NFS crosses network/VFS and often VM boundaries, so each subsystem
adds its usual stack use footprint to the overall picture.  NFS reconnect
is especially hard in this regard, and in case the direct dispatch is
triggered (in this case over loopback) machine has no chance.

The backtrace you cited just reinforces the point that the i386 commit
is wrong. It breaks the workload we aims as the main FreeBSD target,
which is generic-purpose Unix workstation or server. The commit tries
to make defaults fit for specific appliance load of router with IPSEC
or ZFS on i386, which require extensive tuning on i386 anyway. Worse,
as you prove above, the commit in fact does not fix the issues, it only
papers over them and move easily triggered faults from one configuration
to another.
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to