taskqgroup_adjust kernel panic
Mark Johnston
markj at FreeBSD.org
Mon Sep 5 21:49:49 UTC 2016
On Mon, Sep 05, 2016 at 01:55:38PM -0400, Shawn Webb wrote:
> Hey all,
>
> I'm at revision 3872750 of the hardened/current/drm-next-4.7 branch in
> the HardenedBSD/hardenedBSD-playground repo. I've gotten this kernel
> panic a couple times when booting. I'm using full-disk encryption with
> ZFS and encrypted swap. The hardware is a Purism 15 2K laptop.
>
> The panic doesn't happen often nor is there a way I can reproduce it
> 100%.
>
> Here's my `uname -a` output:
>
> FreeBSD hbsd-dev-laptop 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD #0 3872750(hardened/current/drm-next-4.7): Tue Aug 30 17:41:53 EDT 2016 shawn at hbsd-dev-laptop:/usr/obj/usr/src/sys/LATT-SEC amd64
>
> Here's a couple pictures of the panic I took:
>
> https://goo.gl/photos/P5kiwabPYjwQX7Kr8
> https://goo.gl/photos/BWtvBnq7QLnwgRP28
Based on the faulting instruction, the panic probably happened because
qid is uninitialized in the loop that starts with
while ((gtask = LIST_FIRST(>ask_head))) {
I don't know this code very well, so I'm not sure how that can happen. I
suspect iflib_irq_alloc_generic() is buggy: it calls
taskqgroup_attach_cpu(... CPU_FFS(&cpus) ...);
and CPU_FFS returns 1-indexed IDs, but taskqgroup_attach_cpu() pretty
clearly expects 0-indexed CPU IDs. There's a similar bug in find_nth()
in iflib.c.
More information about the freebsd-current
mailing list