[Bug 284073] bnxt: kernel panic on 14.2-RELEASE

2025-01-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284073 --- Comment #20 from Zhenlei Huang --- (In reply to Daniel Porsch from comment #19) So my previous assumption > If `bnxt_dcb_ieee_listapp()` OOB write the on stack variable app[128], then > it make sense that we get `%rbx == 00050

[Bug 284073] bnxt: kernel panic on 14.2-RELEASE

2025-01-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284073 --- Comment #19 from Daniel Porsch --- Created attachment 256886 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256886&action=edit new panic New panic with the latest partch -- You are receiving this mail because: You are the

iflib expert group

2025-01-21 Thread Andriy Gapon
Is there an iflib expert group? Or any forum to talk about iflib design, implementation, correct usage, etc with people who created iflib, worked on iflib, interested in iflib, etc? E.g., like geom@ is for GEOM. -- Andriy Gapon

[Bug 284057] vmxnet3/iflib: crash in vmxnet3_isc_txd_credits_update

2025-01-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284057 --- Comment #12 from Andriy Gapon --- Another thing. There is a curious comment in vmxnet3_msix_intr_assign which I cannot really understand: /* * Don't provide the corresponding rxq irq for reference - * we want the transmit task to be a

[Bug 284057] vmxnet3/iflib: crash in vmxnet3_isc_txd_credits_update

2025-01-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284057 --- Comment #11 from Andriy Gapon --- (In reply to Mark Johnston from comment #10) The spin-lock should be a straightforward and sure-fire way to ensure race-free execution. Thank you for the suggestion. At the same time I've been wonderin

[Bug 284073] bnxt: kernel panic on 14.2-RELEASE

2025-01-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284073 --- Comment #18 from Zhenlei Huang --- (In reply to Daniel Porsch from comment #17) No, the last patch only helps debugging OOB write to on-stack allocated variable. I expect one more kernel panic :) , and I believe this time I found the ro

[Bug 284073] bnxt: kernel panic on 14.2-RELEASE

2025-01-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284073 --- Comment #17 from Daniel Porsch --- (In reply to Zhenlei Huang from comment #16) I applied this patch now, hopefully it doesn't crash again. (In reply to Zhenlei Huang from comment #16) -- You are receiving this mail because: You are

[Bug 284073] bnxt: kernel panic on 14.2-RELEASE

2025-01-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284073 --- Comment #16 from Zhenlei Huang --- Created attachment 256871 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256871&action=edit Patch to assert OOB write on-stack allocated variable -- You are receiving this mail because: Yo

[Bug 284073] bnxt: kernel panic on 14.2-RELEASE

2025-01-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284073 --- Comment #15 from Zhenlei Huang --- Update: After carefully reading the disassembled code, I can confirm the fault address is RIP (0x80b4dee7). For `sysctl_handle_string()`, `req` is the last arg which is passed via register %rc