Date: Tue, 6 Sep 2016 12:25:41 -0400 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Mark Johnston <markj@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: taskqgroup_adjust kernel panic Message-ID: <20160906162541.GA7722@mutt-hardenedbsd> In-Reply-To: <20160905235102.GA42492@mutt-hardenedbsd> References: <20160905175538.GA81799@mutt-hardenedbsd> <20160905215454.GE70066@wkstn-mjohnston.west.isilon.com> <20160905235102.GA42492@mutt-hardenedbsd>
next in thread | previous in thread | raw e-mail | index | archive | help
--tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 05, 2016 at 07:51:02PM -0400, Shawn Webb wrote: > 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 = shawn@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. >=20 > 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. >=20 > 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. I've now verified, using that patch, that qid is always uninitialized in my case. That KASSERT is hit 100% of the time when the laptop is booting up. I've filed a bug report. The problematic code exists in 11-STABLE and 11.0-RELENG as well. Link to bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212418 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 --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXzu4DAAoJEGqEZY9SRW7uiTgQAL6cZbHN4S/E2E1RyuGOCfpk dFp5O895kyYNRWgQgDtCRfHSBQmlv+fbT2LKlW1IY3KL3/nHNHewPSFAZQ1fs71D hewKX+6v/J+qEQFdBmyUXoSzt62JhBzrTQRTr2dmtBi4jsTGhyfp4KOCbyll7w/7 vuM+63ZWUq5IZ4VQFg0SQrF/7hMEevDiHGcX/6lFfESo5D1y1ZTB1vE0JSRKyHEm q0gtmn+2SPLw+dsXgsVpswmDE8OfiKkAKIcDHg2PPMXX4j/g9Fv0Ako3r1DXL00h AooITS9gdt1ydr7+kD9DaSADa7Ms3caT4VMesGxd8Kah3cM5t3SIUkv8m0d8aQ0K 0zg2k99ZGMMdgEOJ9lWXyFwQLRDcEcz3btHKxswJjOVU/aQ2pCNvATJ7Kgis1wde 64fYb/vDDnH5KX/XSzgeKUE4eTIdWWcTa9ZeiA9G1hq+ajFRa/b5z6Q403WUJase MxkzXnpaSsqVVRIm7jnnC0KefMG/PbYs9Xy14WfPnFRqmvI6rnA2sRWs3LQxS7fu rG4nV8YVGobyMXnSvfa1m+In4zQCwf64xgAZ3ePhocVc9LdJ1Xfzvb2zEl5eHTOZ pZMKabOpc4xWfXsrygCk5vC1vCim/l1qPySomCkiW+aOt2KjV2IjzqmzRDtK+JS5 69O35nuLp6QtVcY7aPaZ =OQeh -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160906162541.GA7722>