svn commit: r326758 - in head/sys/i386: conf include

[John Baldwin]

On 12/14/17 3:34 AM, 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

In case it is not clear, it is not _just_ NFS that is broken.  clang is
_known_ to be broken.  When I build a FreeBSD/mips64 kernel with clang,
_any_ simple NFS op triggers a kernel stack overflow.  Kernels compiled
with GCC do not.  I would really appreciate investigating the clang vs gcc
on i386 to determine if this issue is platform-specific or not.  If clang
is stack hungry on all architectures then we need to be aware of that
problem.  (clang 5 on MIPS also has the lovely property that it doesn't
save $RA when it calls a dead2 function, so the stack trace for the kernel
stack overflow from ddb is useless and ends when the trap handler calls
panic, it never makes it back into the original stack which overflowed.)

-- 
John Baldwin