Re: taskqgroup_adjust kernel panic

From: Mark Johnston <markj_at_FreeBSD.org>
Date: Mon, 5 Sep 2016 14:54:54 -0700
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(&gtask_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.
Received on Mon Sep 05 2016 - 19:49:49 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:07 UTC