https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270841
Bug ID: 270841 Summary: fstat causes kernel panic with nullfs mount from NFS Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: henry.hu...@gmail.com So my setup is like this: /mnt/nashome - NFS mount /mnt/nashome/doc -> $HOME/doc - nullfs mount I'm running a fairly recent head (1400083). I can try a newer one if needed. It seems like that I can always hit a kernel panic when I try to run lsof or fstat. If I remove all the nullfs mounts from NFS, there's no panic. Most kernel dumps seem to be garbage, but I got one which is kind of okay: Reading symbols from /usr/obj/usr/src/amd64.amd64/sys/MYKERNEL/kernel.full... Unread portion of the kernel message buffer: Fatal double fault rip 0xffffffff888575e8 rsp 0xfffffe017d504fd0 rbp 0xfffffe017d505020 rax 0xfffff8011ca70800 rdx 0xffffffff888a2fe5 rbx 0xfffff8010b70f000 rcx 0 rsi 0xfffffe0152774000 rdi 0xfffff8011ca73600 r8 0xe r9 0x1 r10 0xfffff8011c7856b0 r11 0 r12 0 r13 0x32 r14 0xfffffe017bbd0e40 r15 0 rflags 0x10282 cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b fsbase 0x4d74bced120 gsbase 0xffffffff83016000 kgsbase 0 cpuid = 6; apic id = 18 panic: double fault cpuid = 6 time = 1681482613 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0039268da0 vpanic() at vpanic+0x185/frame 0xfffffe0039268e00 panic() at panic+0x43/frame 0xfffffe0039268e60 dblfault_handler() at dblfault_handler+0x1ce/frame 0xfffffe0039268f20 Xdblfault() at Xdblfault+0xd7/frame 0xfffffe0039268f20 --- trap 0x17, rip = 0xffffffff888575e8, rsp = 0xfffffe017d504fd0, rbp = 0xfffffe017d505020 --- re_8125_pad() at re_8125_pad+0x28/frame 0xfffffe017d505020 re_start() at re_start+0x3e7/frame 0xfffffe017d5070d0 if_transmit_default() at if_transmit_default+0xf5/frame 0xfffffe017d507120 ether_output_frame() at ether_output_frame+0xa3/frame 0xfffffe017d507150 ether_output() at ether_output+0x6bd/frame 0xfffffe017d5071d0 ip_output_send() at ip_output_send+0xa4/frame 0xfffffe017d507200 ip_output() at ip_output+0x1222/frame 0xfffffe017d507310 tcp_default_output() at tcp_default_output+0x1f60/frame 0xfffffe017d5074f0 tcp_usr_send() at tcp_usr_send+0x27b/frame 0xfffffe017d5075a0 sosend_generic() at sosend_generic+0x605/frame 0xfffffe017d507670 sosend() at sosend+0x3b/frame 0xfffffe017d5076a0 clnt_vc_call() at clnt_vc_call+0x511/frame 0xfffffe017d507800 clnt_reconnect_call() at clnt_reconnect_call+0x2e8/frame 0xfffffe017d5078c0 newnfs_request() at newnfs_request+0xa96/frame 0xfffffe017d507a70 nfscl_request() at nfscl_request+0x54/frame 0xfffffe017d507ac0 nfsrpc_accessrpc() at nfsrpc_accessrpc+0x11a/frame 0xfffffe017d507c60 nfs34_access_otw() at nfs34_access_otw+0x43/frame 0xfffffe017d507d90 nfs_access() at nfs_access+0x3d5/frame 0xfffffe017d507e20 vop_sigdefer() at vop_sigdefer+0x2b/frame 0xfffffe017d507e50 vn_dir_check_exec() at vn_dir_check_exec+0x4e/frame 0xfffffe017d507e90 nfs_lookup() at nfs_lookup+0x127/frame 0xfffffe017d5081b0 vop_sigdefer() at vop_sigdefer+0x2b/frame 0xfffffe017d5081e0 vfs_lookup() at vfs_lookup+0x44c/frame 0xfffffe017d508280 namei() at namei+0x1ff/frame 0xfffffe017d508300 vn_open_cred() at vn_open_cred+0x565/frame 0xfffffe017d508460 vop_stdvptocnp() at vop_stdvptocnp+0x1b4/frame 0xfffffe017d508710 vop_sigdefer() at vop_sigdefer+0x2b/frame 0xfffffe017d508740 vn_vptocnp() at vn_vptocnp+0x199/frame 0xfffffe017d5087b0 null_vptocnp() at null_vptocnp+0xb9/frame 0xfffffe017d508810 vn_vptocnp() at vn_vptocnp+0x199/frame 0xfffffe017d508880 vn_fullpath_dir() at vn_fullpath_dir+0xf9/frame 0xfffffe017d5088f0 vn_fullpath_any() at vn_fullpath_any+0x55/frame 0xfffffe017d508930 vn_fullpath() at vn_fullpath+0xd2/frame 0xfffffe017d508980 vn_fill_kinfo_vnode() at vn_fill_kinfo_vnode+0x42/frame 0xfffffe017d508a90 vn_fill_kinfo() at vn_fill_kinfo+0x45/frame 0xfffffe017d508ac0 kern_proc_filedesc_out() at kern_proc_filedesc_out+0x4b8/frame 0xfffffe017d508b50 sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x8c/frame 0xfffffe017d508bd0 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x90/frame 0xfffffe017d508c20 sysctl_root() at sysctl_root+0x28a/frame 0xfffffe017d508ca0 userland_sysctl() at userland_sysctl+0x17e/frame 0xfffffe017d508d50 sys___sysctl() at sys___sysctl+0x5c/frame 0xfffffe017d508e00 amd64_syscall() at amd64_syscall+0x11a/frame 0xfffffe017d508f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe017d508f30 --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x4d74d32178a, rsp = 0x4d74b8c0a68, rbp = 0x4d74b8c0aa0 --- Uptime: 1m42s Dumping 2044 out of 32486 MB: (CTRL-C to abort) ..1% (CTRL-C to abort) ..11% (CTRL-C to abort) (CTRL-C to abort) ..21%..31%..41%..51%..61%..71%..81%..91% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59 59 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) where #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59 #1 dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:403 #2 0xffffffff807a64b8 in dumpsys (di=0x0) at /usr/src/sys/x86/include/dump.h:87 #3 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:432 #4 kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:539 #5 0xffffffff807a6a23 in vpanic (fmt=0xffffffff80bc0f3f "double fault", ap=0xfffffe0039268e40) at /usr/src/sys/kern/kern_shutdown.c:983 #6 0xffffffff807a6823 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:907 #7 0xffffffff80b6d83e in dblfault_handler (frame=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:1014 #8 <signal handler called> #9 0xffffffff888575e8 in ?? () from /boot/modules/if_re.ko Backtrace stopped: Cannot access memory at address 0xfffffe017d504fd0 (kgdb) It seems like that the stack is corrupted. -- You are receiving this mail because: You are the assignee for the bug.