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.
