Date: Mon, 5 Sep 2016 19:51:02 -0400 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Mark Johnston <markj@FreeBSD.org> Cc: freebsd-current@freebsd.org, mmacy@nextbsd.org Subject: Re: taskqgroup_adjust kernel panic Message-ID: <20160905235102.GA42492@mutt-hardenedbsd> In-Reply-To: <20160905215454.GE70066@wkstn-mjohnston.west.isilon.com> References: <20160905175538.GA81799@mutt-hardenedbsd> <20160905215454.GE70066@wkstn-mjohnston.west.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--4bRzO86E/ozDv8r1 Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 05, 2016 at 02:54:54PM -0700, Mark Johnston wrote: > On Mon, Sep 05, 2016 at 01:55:38PM -0400, Shawn Webb wrote: > > Hey all, > >=20 > > 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. > >=20 > > The panic doesn't happen often nor is there a way I can reproduce it > > 100%. > >=20 > > Here's my `uname -a` output: > >=20 > > 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 sh= awn@hbsd-dev-laptop:/usr/obj/usr/src/sys/LATT-SEC amd64 > >=20 > > Here's a couple pictures of the panic I took: > >=20 > > https://goo.gl/photos/P5kiwabPYjwQX7Kr8 > > https://goo.gl/photos/BWtvBnq7QLnwgRP28 >=20 > Based on the faulting instruction, the panic probably happened because > qid is uninitialized in the loop that starts with >=20 > while ((gtask =3D LIST_FIRST(>ask_head))) { >=20 > 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 >=20 > taskqgroup_attach_cpu(... CPU_FFS(&cpus) ...); >=20 > 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. I think you hit the nail right on the head. Attached is a patch that doesn't fix the underlying issue, but at least detects improperly setting qid. It'll throw a KASSERT if qid isn't set properly. I'll study this code a bit more within the next couple days and I hope to have a full patch to address the underlying issue. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --C7zPtVaVf+AK4Oqc Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="2016-09-05_subr_gtaskqueue.c-rev-01.patch" Content-Transfer-Encoding: quoted-printable diff --git a/sys/kern/subr_gtaskqueue.c b/sys/kern/subr_gtaskqueue.c index 9423dd8..1a086c9 100644 --- a/sys/kern/subr_gtaskqueue.c +++ b/sys/kern/subr_gtaskqueue.c @@ -790,6 +790,7 @@ _taskqgroup_adjust(struct taskqgroup *qgroup, int cnt, = int stride) =20 while ((gtask =3D LIST_FIRST(>ask_head))) { LIST_REMOVE(gtask, gt_list); + qid=3D-1; if (gtask->gt_cpu =3D=3D -1) qid =3D taskqgroup_find(qgroup, gtask->gt_uniq); else { @@ -799,6 +800,7 @@ _taskqgroup_adjust(struct taskqgroup *qgroup, int cnt, = int stride) break; } } + KASSERT(qid !=3D -1, ("_taskgroup_adjust: qid cannot be -1")); qgroup->tqg_queue[qid].tgc_cnt++; LIST_INSERT_HEAD(&qgroup->tqg_queue[qid].tgc_tasks, gtask, gt_list); --C7zPtVaVf+AK4Oqc-- --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXzgTjAAoJEGqEZY9SRW7uQzsQAIZiFyBaxOlWQwMas6f3s81F InMi/HP5keo7sToBxky5lBIDC9tQ3N/YVhDyt6IGDHuuNequ7H2KAl3g6IF+/Nj2 rL06tbVwvKfrMNhO0ADMXQ7Y6xj/KlZOEYS0UbDlA7WOP7gTkgygvKQElb7YKUbC TTiZo9me9jNeYewY66dDACasSVSPvoCdQFDyubp1C+8FNSxpSfiuAV5QeLRD/UAO iu7svhL0O8luMuk9IhymKSHVSp6NUDBcfeo4OTa/FknEz1e5d+I27PvP15+1OlZb NsSEA+vsNe0Go9M2hZ32ZV+HK1tE2BkYXozINc1H7oiwGtaLDoekB03iZIwbO+lz pHu7UbgZukjQpygMncHlaC+C4VtaU0xaF6ZVVF4wjPywrqEzk5lpK7eBcsLgcBGa 3Y0cuMADKkfxC27/UErsXWdiWS6l9dBkXFVxFmw/erbLKA7b1PGFLmYE1R3NRLbm 7LulOvC1dEhodxPZ/8Gl1EEnOm3GvbiCdaoapYsPCJQmL1ZWmY2/SxeD5mB92FOx PLejNJxRwj7mpibDJCGFgLb0bBvO0b8U+weQrSlync6zEMOcSy+FC1Hs0Eg+YkVi rzZgEAfPfcBmzIJKTJexVe/8N9GW+0VAIZE8zB806wFiq2upZB76pog7DygYWdgv G6EpvIU0dffbM+drnlRd =S8W4 -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160905235102.GA42492>