Date: Tue, 19 Feb 2019 18:43:28 -0500 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <20190219234328.wrmteippr6vbg2fr@mutt-hbsd> In-Reply-To: <201902192335.x1JNZu53080578@repo.freebsd.org> References: <201902192335.x1JNZu53080578@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--hnirbtvcopw34t5o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2019 at 11:35:56PM +0000, Pawel Jakub Dawidek wrote: > Author: pjd > Date: Tue Feb 19 23:35:55 2019 > New Revision: 344316 > URL: https://svnweb.freebsd.org/changeset/base/344316 >=20 > Log: > The way ZFS searches for its vdevs is the following: first it looks for > a vdev that has the same name as the one stored in metadata and that has > all VDEV labels in place. If it cannot find a GEOM provider with the gi= ven > name and all VDEV labels it will scan all GEOM providers for the best m= atch > (the most VDEV labels available), but here the name is ignored. > =20 > In case the ZFS pool is created, eg. using GPT partition label: > =20 > # zpool create tank /dev/gpt/tank > =20 > everything works, and on every import ZFS will pick /dev/gpt/tank and > not /dev/da0p4. > =20 > The problem occurs when da0p4 is extended and ZFS is unable to find all > VDEV labels in /dev/gpt/tank anymore (the VDEV labels stored at the end > of the partition are now somewhere else). In this case it will scan all > GEOM providers and will pick the first one with the best match, ie. da0= p4. > =20 > Fix this problem by checking the VDEV/provider name even if we get the = same > match. If the name is the same as the one we have in pool's metadata, p= refer > this GEOM provider. > =20 > Reported by: oshogbo, Michal Mroz <m.mroz@fudosecurity.com> > Tested by: Michal Mroz <m.mroz@fudosecurity.com> > Obtained from: Fudo Security >=20 > Modified: > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c At the risk of painting a bikeshed a lovely color of neon purple, I'm curious about if/how these types of commits get merged upstream to (OpenZFS|Illumos|ZFS On Linux|where ever ZFS upstream is now|I'm very confused|is anyone else confused where upstream is?). Who is upstream? Is work like this going to remain as a downstream patch to ZFS? Or is FreeBSD going to work to upstream this type of work? I hope my curiousity doesn't offend anyone. ;) Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --hnirbtvcopw34t5o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlxslJwACgkQaoRlj1JF bu5s9A//alw1McK6fXYjINgJ6OhifqC+AxXBvmjNSUAETHX8RTGt+zUfG5eAan81 UX/T7tXSR2nn1yDy5tUxCpNiKajTG1KDIkw3gr5JLMOxyVCdCUoqrwKcVR2hk2yK Cg9+6MVUfDPeRb1c2qCxdRFExUWRG7eApLuCYuTCqsJgrGvURtrmV8hpPXALuli7 +7vsqIvXCIiiemwbl8gC5F96zVBefn8tJEJ1HTmPTajNR9BvmY+4I7W3q/JMlN8N hBvRgy1agyt6Krf2uGqE3O6zXvHL6XebGYESFdR34/hvRQ+T54IKQ3fXxa+XXQjp r3VNVx7G5ky+z5Cly0isYwdF8nqFGlEPNEVqYtckXG9qbYUPnNgU2AyBR0rlM3Xc KHwbKo48Bb9a9l7nDE6qmzW83ENd2V/GK2u7zxFIHWBth9plC6NLTu15aU6np/4L 1szowoMI05xHjIsVFQkwdUd89Oe1ijoNFWd2NM66b9nLQWF5GPMQM0NP5x/wbK2N 8h0zLXJXacDm9XhZPMgHKfRFVyCdx24jF45EmV00DFbM2lrAkwRXGZRGxbvajq9p tJ21POlVmFx2bWN8uRRZ/04LnqzLu0mExGocPZ0EMvK3WngT3vDxLmSee6ZPVC/O wTJ60T90VpEqPuKRO+tQSvoPF2FkiVKf/EQZU7zj1M1wzzxgPLk= =igqV -----END PGP SIGNATURE----- --hnirbtvcopw34t5o--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190219234328.wrmteippr6vbg2fr>