[Bug 275483] accessing stalled smbfs mount caused kernel panic

From: <bugzilla-noreply_at_freebsd.org>
Date: Sat, 02 Dec 2023 11:58:14 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275483

            Bug ID: 275483
           Summary: accessing stalled smbfs mount caused kernel panic
           Product: Base System
           Version: 13.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: 000.fbsd@quip.cz

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 0x0, 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

-- 
You are receiving this mail because:
You are the assignee for the bug.