Bug 212418 - kernel panic in _taskqgroup_adjust - uninitialized variable
Summary: kernel panic in _taskqgroup_adjust - uninitialized variable
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL: https://reviews.freebsd.org/D7799
Keywords: crash, needs-qa, patch
Depends on:
Blocks:
 
Reported: 2016-09-06 16:06 UTC by Shawn Webb
Modified: 2019-04-08 19:16 UTC (History)
6 users (show)

See Also:
koobs: mfc-stable11?
koobs: mfc-stable10?

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Shawn Webb 2016-09-06 16:06:55 UTC 
The variable qid in the fuunction _taskqgroup_adjust in sys/kern/subr_gtaskqueue.c is used uninitialized in some instances. On my Purism Librem 15, this variable is always unitialized.

I wrote a little patch to detect when it hasn't been set, but is being used here: https://github.com/HardenedBSD/hardenedBSD-playground/commit/7c3b5f7624459e8108873861442be5ce9f497ad7

100% of the time on the Librem 15 at bootup, qid will end up hitting the KASSERT. I haven't studied the code to figure out a fix, yet. Without the patch, though, the code in question will cause a write to an arbitrary location, occasionally causing a kernel panic at bootup. With the patch, the system is unbootable since qid is always -1.
Comment 1 Shawn Webb 2016-09-06 16:24:50 UTC 
The problematic code exists in releng/11.0 as well.
Comment 2 Mark Johnston freebsd_committer freebsd_triage 2016-09-06 16:49:23 UTC 
(In reply to Shawn Webb from comment #1)
For what it's worth, taskqgroup is only used by iflib, which won't have any consumer drivers in 11.0.
Comment 3 Conrad Meyer freebsd_committer freebsd_triage 2016-09-06 17:15:38 UTC 
https://reviews.freebsd.org/D7799
Comment 4 Conrad Meyer freebsd_committer freebsd_triage 2016-09-06 17:16:01 UTC 
(In reply to Mark Johnston from comment #2)
Yes, but iflib triggers this even without drivers, via SYSINIT.
Comment 5 Conrad Meyer freebsd_committer freebsd_triage 2016-09-06 17:18:32 UTC 
via

iflib.c:483
TASKQGROUP_DEFINE(if_io_tqg, mp_ncpus, 1);

gtaskqueue.h:115
        taskqgroup_adjust(qgroup_##name, (cnt), (stride));

Although it still looks like iflib_irq_alloc_generic is deadcode and shouldn't be causing this.
Comment 6 Conrad Meyer freebsd_committer freebsd_triage 2016-09-06 17:19:42 UTC 
Maybe Nathan didn't fix every !sparse CPU assumption in gtaskqueue.
Comment 7 Shawn Webb 2016-09-06 17:55:04 UTC 
Adding Nathan Whitehorn to the bug to see if he has any input.
Comment 8 Conrad Meyer freebsd_committer freebsd_triage 2016-10-18 15:58:34 UTC 
Probably addressed in r307560, r307561, r307566, r307567.
Comment 9 Ed Maste freebsd_committer freebsd_triage 2019-04-08 15:32:01 UTC 
Shawn can you confirm?
Comment 10 Shawn Webb 2019-04-08 15:36:35 UTC 
(In reply to Ed Maste from comment #9)
Not anymore. The Purism Librem 15 didn't survive even four months of being around my wife. I now use a Dell Precision 7510. We could probably close this nearly-three-year-old ticket with OVERCOMEBYEVENTS.
Comment 11 Ed Maste freebsd_committer freebsd_triage 2019-04-08 19:16:29 UTC 
Presumed fixed by one of the commits identified by cem@