On Sun, Mar 20, 2022 at 09:57:03PM +0100, Sven M. Hallberg wrote:
> >Synopsis: Kernel page fault in iwm (related to suspend?)
> >Category: kernel
> >Environment:
> System : OpenBSD 7.1
> Details : OpenBSD 7.1-beta (GENERIC.MP) #422: Tue Mar 15 11:28:22
> MDT 2022
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> A few minutes into regular use after resume, the kernel panicked with
> a page fault. The machine is a Thinkpad X250, running a recent snapshol.
> I was using X with two xterms open (running radare2 and vim). The wifi
> interface was enabled but not connected to any network, as far as I am
> aware. I was riding a public bus at the time, so any kind of network
> could have been passing by. I recall similar crashes in the past and it
> *seems* that they like to happen after a suspend (close lid) and resume,
> though suspend usually works fine.
>
> Screenshots of ddb output are attached.
The important bit from the screenshots is:
Stopped at _rb_insert+0x27d: cmpq %r12,0x8(%rcx)
We get to _rb_insert via ieee80211_setup_node() when a beacon is received
and we want to create a new entry for this node in the nodes tree.
Reading objdump -S output, to me it looks like the crash happens here:
static inline void
rbe_insert_color(const struct rb_type *t, struct rb_tree *rbt,
struct rb_entry *rbe)
{
struct rb_entry *parent, *gparent, *tmp;
while ((parent = RBE_PARENT(rbe)) != NULL &&
RBE_COLOR(parent) == RB_RED) {
gparent = RBE_PARENT(parent);
if (parent == RBE_LEFT(gparent)) { <-- crash
If my assumption is correct, the failing memory access would be
gparent->rbt_left which matches offset 0x8 of the failing instruction.
It seems the RB tree is in an invalid state. If the parent is red then
there should be a grand-parent. I don't know how this can happen.
Does anyone have an idea?
