svn commit: r344316 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Shawn Webb]

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
> 
> 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 given
>   name and all VDEV labels it will scan all GEOM providers for the best match
>   (the most VDEV labels available), but here the name is ignored.
>   
>   In case the ZFS pool is created, eg. using GPT partition label:
>   
>   	# zpool create tank /dev/gpt/tank
>   
>   everything works, and on every import ZFS will pick /dev/gpt/tank and
>   not /dev/da0p4.
>   
>   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. da0p4.
>   
>   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, prefer
>   this GEOM provider.
>   
>   Reported by:	oshogbo, Michal Mroz <m.mroz at fudosecurity.com>
>   Tested by:	Michal Mroz <m.mroz at fudosecurity.com>
>   Obtained from:	Fudo Security
> 
> 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,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20190219/3ed247f1/attachment.sig>