Bug 275483

Summary: accessing stalled smbfs mount caused kernel panic
Product: Base System Reporter: Miroslav Lachman <000.fbsd>
Component: kernAssignee: freebsd-fs (Nobody) <fs>
Status: New ---    
Severity: Affects Only Me CC: net, zarychtam
Priority: --- Keywords: crash
Version: 13.2-RELEASE   
Hardware: Any   
OS: Any   

Description Miroslav Lachman 2023-12-02 11:58:14 UTC
We have 8 machines in a LAN, all of them have mounted 3 smbfs shares from one Windows server which became unavailable for a few days. Plus couple of smbfs mounts from another Windows machines (without any problem at this time) There were long timeouts accessing the mountpoints in /mnt/ but everything was stable. Once the network issue of problematic Windows machine was resolved, I tried to umount and mount one of the problematic smbfs share on one machine which went good but I did not touch other stalled mounts on other machines. All machines paniced at night at 3 AM when periodic daily scripts start to check the system, mounts etc. All machines have the same message logged:

Fatal trap 12: page fault while in kernel mode
cpuid = 7; apic id = 0e
fault virtual address       = 0x0
fault code          = supervisor write data, page not present
instruction pointer = 0x20:0xffffffff82384293
stack pointer               = 0x28:0xfffffe0140dcbd40
frame pointer               = 0x28:0xfffffe0140dcbde0
code segment                = base rx0, limit 0xfffff, type 0x1b
                    = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process             = 1933 (smbiod5)
trap number         = 12
panic: page fault
cpuid = 7
time = 1701482461
KDB: stack backtrace:
#0 0xffffffff80c53f45 at kdb_backtrace+0x65
#1 0xffffffff80c068c1 at vpanic+0x151
#2 0xffffffff80c06763 at panic+0x43
#3 0xffffffff810b1fa7 at trap_fatal+0x387
#4 0xffffffff810b1fff at trap_pfault+0x4f
#5 0xffffffff81088fe8 at calltrap+0x8
#6 0xffffffff82384a49 at smb_iod_sendrq+0x129
#7 0xffffffff82385139 at smb_iod_sendall+0xb9
#8 0xffffffff82385b56 at smb_iod_thread+0x156
#9 0xffffffff80bc314e at fork_exit+0x7e
#10 0xffffffff8108a05e at fork_trampoline+0xe
Uptime: 9d5h56m26s
Dumping 2259 out of 29662 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Dump complete

I am curious why the machines paniced after the issue was fixed.

The machines are all the same configuration = FreeBSD 13.2-p5 amd64 with GENERIC kernel.
One share is mounted: smbfs, noexec, nosuid, read-only
Other two: smbfs, noexec, nosuid