Description Alan Somers 2023-06-21 01:21:57 UTC

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 rx0, 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.