[Bug 272117] bnxt: kernel crash with sysctl and jumbo frames

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272117

            Bug ID: 272117
           Summary: bnxt: kernel crash with sysctl and jumbo frames
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: asomers@FreeBSD.org

I can reliably crash the kernel just by doing "sysctl dev.bnxt.0" if the
interface has been configured with jumbo frames.  It seems that the trigger is
whether the interface has ever been configured with jumbo frames, not whether
it currently uses them.  If I boot with jumbo frames, then do "ifconfig lagg0
mtu 1500", I can still trigger the panic.

This happens on a custom kernel build based on 13.1-RELEASE.

/etc/rc.conf:
ifconfig_bnxt0="up"
ifconfig_bnxt3="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp -lacp_fast_timeout 10.2.172.79/23 laggport bnxt0
laggport bnxt3"
vlans_lagg0="173"
ifconfig_lagg0_173="10.2.174.79/23"
defaultrouter="10.2.172.1"

Steps to Reproduce:
==================

$ sysctl dev.bnxt.0
...
dev.bnxt.0.iflib.txq00.cpu: 0
<PANIC>

Stack trace:
============
Fatal trap 12: page fault while in kernel mode
cpuid = 21; apic id = 8a
fault virtual address   = 0xc00000148
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80d6dffb
stack pointer           = 0x28:0xfffffe0d24c4ea90
frame pointer           = 0x28:0xfffffe0d24c4ebd0
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         = 3220 (sysctl)
trap number             = 12
panic: page fault
cpuid = 21
time = 1687302737
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0d24c4e850
vpanic() at vpanic+0x17f/frame 0xfffffe0d24c4e8a0
panic() at panic+0x43/frame 0xfffffe0d24c4e900
trap_fatal() at trap_fatal+0x385/frame 0xfffffe0d24c4e960
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe0d24c4e9c0
calltrap() at calltrap+0x8/frame 0xfffffe0d24c4e9c0
--- trap 0xc, rip = 0xffffffff80d6dffb, rsp = 0xfffffe0d24c4ea90, rbp =
0xfffffe0d24c4ebd0 ---
mp_ndesc_handler() at mp_ndesc_handler+0x7b/frame 0xfffffe0d24c4ebd0
sysctl_root_handler_locked() at sysctl_root_handler_locked+0x90/frame
0xfffffe0d24c4ec20
sysctl_root() at sysctl_root+0x271/frame 0xfffffe0d24c4eca0
userland_sysctl() at userland_sysctl+0x173/frame 0xfffffe0d24c4ed50
sys___sysctl() at sys___sysctl+0x5c/frame 0xfffffe0d24c4ee00
amd64_syscall() at amd64_syscall+0x775/frame 0xfffffe0d24c4ef30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0d24c4ef30
--- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8011a11ca, rsp =
0x7fffffffc5a8, rbp = 0x7fffffffc5e0 ---
KDB: enter: panic

From GDB, it seems that the sysctl that triggers the panic is
dev.bnxt.0.iflib.override_nrxds.  And in mp_ndesc_handler, the value of
ctx->ifc_sctx is 0xc00000000 , which doesn't look right, because it ought to be
a pointer.

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