ZVOL 'volmode=dev' no longer hides partitions in Linux 5.17.1

[Wenri]

System information

Type	Version/Name
Distribution Name	Ubuntu
Distribution Version	21.10 (Impish Indri)
Kernel Version	5.17.1-xanmod1
Architecture	x86_64
OpenZFS Version	2.1.4-0york0

Describe the problem you're observing

Two commits in Linux 5.17 (ChangeLog):

1ebe2e5f9d68e94c ("block: remove GENHD_FL_EXT_DEVT")
46e7eac647b34ed4 ("block: rename GENHD_FL_NO_PART_SCAN to GENHD_FL_NO_PART")

Removed GENHD_FL_EXT_DEVT and renamed GENHD_FL_NO_PART_SCAN. Both macros are referenced in module/os/linux/zfs/zvol_os.c. As a result, in function zvol_alloc, zso->zvo_disk->flags is not configured to hide the partition, leaving only:

zso->zvo_disk->minors = 1;

This partial configuration seems to affect the /lib/udev/zvol_id, causing it produces wrong partition name for zvol device node (e.g. /dev/zd0p1), which could overwrite the symlink of /dev/zd0 in the udev rule 60-zvol.rules.

In short, using zvol under linux kernel 5.17 with volmode=dev could result in wrong symbol link in /dev/zvol/.

Describe how to reproduce the problem

Compile and Install ZFS under Linux kernel 5.17

zfs create -s -V 100g -o volmode=dev dpool/testvol  # create a zvol
parted /dev/dpool/testvol  # partition the zvol
zpool export dpool && zpool import dpool  # export and import the pool to see the wrong symbol link

Include any warning/errors/backtraces from the system logs

>/dev/zvol/dpool? sudo zfs get volmode dpool/win10 dpool/win10gpu
NAME            PROPERTY  VALUE    SOURCE
dpool/win10     volmode   dev      local
dpool/win10gpu  volmode   dev      local
>/dev/zvol/dpool? ls -lah win10 win10-*
lrwxrwxrwx 1 root root  9 Apr  4 21:57 win10 -> ../../zd0
lrwxrwxrwx 1 root root 11 Apr  4 21:57 win10-part10 -> ../../zd0p3
lrwxrwxrwx 1 root root 11 Apr  4 21:57 win10-part11 -> ../../zd0p4
lrwxrwxrwx 1 root root 11 Apr  4 21:57 win10-part8 -> ../../zd0p1
lrwxrwxrwx 1 root root 11 Apr  4 21:57 win10-part9 -> ../../zd0p2
>/dev/zvol/dpool? ls -lah win10gpu*
lrwxrwxrwx 1 root root 12 Apr  4 22:17 win10gpu -> ../../zd16p1
lrwxrwxrwx 1 root root 12 Apr  4 22:17 win10gpu-part1 -> ../../zd16p2
lrwxrwxrwx 1 root root 12 Apr  4 22:17 win10gpu-part2 -> ../../zd16p3
lrwxrwxrwx 1 root root 12 Apr  4 22:17 win10gpu-part3 -> ../../zd16p4

Possible workarounds

The following patch can solve the problem:

--- a/module/os/linux/zfs/zvol_os.c	2022-04-05 19:10:14.897022899 +0800
+++ b/module/os/linux/zfs/zvol_os.c	2022-04-05 19:02:57.019555880 +0800
@@ -917,6 +917,8 @@
 #endif
 #if defined(GENHD_FL_NO_PART_SCAN)
 		zso->zvo_disk->flags |= GENHD_FL_NO_PART_SCAN;
+#else
+		zso->zvo_disk->flags |= GENHD_FL_NO_PART;
 #endif
 	}
 	zso->zvo_disk->first_minor = (dev & MINORMASK);

But I believe there are better solution for best compatibility of all kernel versions.

[behlendorf]

@Wenri thanks for catching this and doing the legwork to determine where it was introduced. I've gone ahead and opened PR #13297 with a fix which is almost the same as what you proposed, and is compatible with kernels back to 3.10. If you could independently verify it resolves the issue that would be helpful.