[Bug 285813] Panic (NULL deref) in arptimer

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

Kristof Provost <kp@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kp@freebsd.org

--- Comment #13 from Kristof Provost <kp@freebsd.org> ---
We have at least one pfSense (CE 2.8.0, which is basically FreeBSD main from a
few months ago) user running into this panic as well.
We've obtained one core dump, which I'm not entirely sure is the same problem.

The relevant bits:
#16 <signal handler called>
#17 callout_process (now=now@entry=4696905619631) at
/var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/kern/kern_timeout.c:498
#18 0xffffffff80c82366 in handleevents (now=now@entry=4696905619631,
fake=fake@entry=0)
    at
/var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/kern/kern_clocksource.c:212
#19 0xffffffff80c82f56 in timercb (et=0xffffffff82b2d3c8 <lapic_et>,
arg=<optimized out>)
    at
/var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/kern/kern_clocksource.c:353
#20 0xffffffff813b3cab in lapic_handle_timer (frame=<optimized out>)
    at
/var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/x86/x86/local_apic.c:1324
#21 <signal handler called>
#22 0xffffffff804eb162 in acpi_cpu_idle (sbt=<optimized out>) at
/var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/dev/acpica/acpi_cpu.c:1167
#23 0xffffffff812ab556 in cpu_idle_acpi (sbt=404313140) at
/var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/x86/x86/cpu_machdep.c:589
#24 0xffffffff812ab60d in cpu_idle (busy=0) at
/var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/x86/x86/cpu_machdep.c:678
#25 0xffffffff80d2ce36 in sched_idletd (dummy=dummy@entry=0x0) at
/var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/kern/sched_ule.c:3058
#26 0xffffffff80caf53b in fork_exit (callout=0xffffffff80d2c8f0 <sched_idletd>,
arg=0x0, frame=0xfffffe015840bf40)

We've somehow wound up with a struct callout entry in cc->cc_callwheel[] that's
entirely zeroed out.

That left me wondering if we're somehow freeing an llentry without stopping the
callout.
I'm not sure if llentry_free()'s 'if (callout_stop() > 0)' is correct. The man
page claims callout_stop() can return -1, 0 or 1, and I wonder if the '0' case
(i.e. the callout is currently running and cannot be stopped) is leaving us in
a scenario where the callout will reschedule itself but llentry_free() frees
it.
That's mostly speculation, I'm not familiar enough with the relevant code for
much more than that.

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