Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Jan 2016 09:13:33 -0500
From:      Shawn Webb <shawn.webb@hardenedbsd.org>
To:        Alan Somers <asomers@FreeBSD.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r294329 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys
Message-ID:  <20160124141333.GA19117@mutt-hardenedbsd>
In-Reply-To: <201601191700.u0JH0P6k061610@repo.freebsd.org>
References:  <201601191700.u0JH0P6k061610@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 19, 2016 at 05:00:25PM +0000, Alan Somers wrote:
> Author: asomers
> Date: Tue Jan 19 17:00:25 2016
> New Revision: 294329
> URL: https://svnweb.freebsd.org/changeset/base/294329
>=20
> Log:
>   Disallow zvol-backed ZFS pools
>  =20
>   Using zvols as backing devices for ZFS pools is fraught with panics and
>   deadlocks. For example, attempting to online a missing device in the
>   presence of a zvol can cause a panic when vdev_geom tastes the zvol.  B=
etter
>   to completely disable vdev_geom from ever opening a zvol. The solution
>   relies on setting a thread-local variable during vdev_geom_open, and
>   returning EOPNOTSUPP during zvol_open if that thread-local variable is =
set.
>  =20
>   Remove the check for MUTEX_HELD(&zfsdev_state_lock) in zvol_open. Its i=
ntent
>   was to prevent a recursive mutex acquisition panic. However, the new ch=
eck
>   for the thread-local variable also fixes that problem.
>  =20
>   Also, fix a panic in vdev_geom_taste_orphan. For an unknown reason, this
>   function was set to panic. But it can occur that a device disappears du=
ring
>   tasting, and it causes no problems to ignore this departure.
>  =20
>   Reviewed by:	delphij
>   MFC after:	1 week
>   Relnotes:	yes
>   Sponsored by:	Spectra Logic Corp
>   Differential Revision:	https://reviews.freebsd.org/D4986

I've just been bit by this pretty hard. I have a bhyve VM that's backed
by a zvol. The VM is running root-on-zfs. I wrote some experimental code
that's now preventing the VM from booting (kernel panic due to userland
change). Since I can't import the pool, I have no way of fixing the
problem.

I'm probably just going to go revert this commit locally on my box so I
can get some work done.

Thanks,

--=20
Shawn Webb
HardenedBSD

GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

--2oS5YaxWCcQjTEyO
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWpNwKAAoJEGqEZY9SRW7u0MUP/i7mAOrXGAWq9LUGWbZ2Khiq
CIfq9DUKtwDvfEMSqk8tpvyMyqXll68BcFcZBT7lPOOX4DUhkKyYsvhllzu9Yq/a
UHA+tXO/64WEXwTCMKBp3pPARr/wD7BRHturAQMgfsBmjWS3LbNXlle3fSMDfq5f
X83wsvmU7AbYfmLS3twr9dP4kgp+LFcgGLC8zLHE7HkESXq/rEblLxrTUJCkdZuZ
kT79/PkHrr0E8nhyOojCadLHfg1V0toc4Gj03ADHi17G3Bh5P8AZyniZa6fOdXtO
Moc8+yMqqAmwh7J/R1QxNtGATs8oEhjgz+55jRUFVml+qlExC7aXh0PrOHSPkPc7
6890Z3HFSahDYbIfBQcku/O41i4DTOticyaAJ82O2Gc8VI4SZLagziai8RIGyETR
qhqxJP3jP+g3KoF+QIQu72Ea6p/ww67Edweq80oHfSYsKKSRMP/lFrulIc4E1eP9
QHORBECiFnRvU0FQCNSuSeQ9W0IA5/Rl0Du7NNjaGpd+xsNlHKrjy50FmzgG/GWu
HItpdZzQ6QhBbno2mr8AcyL4XoTi9sEWXHeKOWLx9VWqiYCfUKgkFAKh4VoJ+79r
LbtMDbjDYstdnSTL7LUerRSz7iSPs/jI4Esoku4LZoCbV22ao0YiXWysR6BwSl0a
L8pQ/dPnyR8VtAn7QnAb
=1JIc
-----END PGP SIGNATURE-----

--2oS5YaxWCcQjTEyO--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160124141333.GA19117>