Re: bin/57903: umount: Add -d option to umount to detach vnode device

["David H. Gutteridge via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/57903; it has been noted by GNATS.

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/57903: umount: Add -d option to umount to detach vnode
 device
Date: Wed, 26 Mar 2025 21:05:32 -0400

 The existing code doesn't work in all cases. Consider the following an
 uninitiated user (e.g., me) might think could work:
 
 # vndconfig vnd0 riscv64.img
 # dmesg | grep vnd0
 [ 21730.535797] vnd0: GPT GUID: 66d6e832-e832-46d6-b2e8-d66632e8d666
 [ 21730.535797] dk0 at vnd0: "EFI", 163840 blocks at 32768, type: msdos
 [ 21730.535797] dk1 at vnd0: "netbsd-root", 2211840 blocks at 196608,
 type: ffs
 # mount /dev/dk0 /mnt
 # umount -d /mnt
 umount: invalid vnd device: /dev/dk0
 
 Here we have indirection because of wedges: one vnode disk can expose
 more than one potential disk wedge. Even if only one wedge is mounted,
 it won't be cleared because there's a check that expects the mount
 point=C2=A0is directly associated with a vnd device.
 
 	if (strncmp(dev, "/dev/vnd", sizeof("/dev/vnd") - 1)) {
 		if (!all)
 			warnx("invalid vnd device: %s", dev);
 		return -1;
 	}
 
 Regardless, this layering means we can't simply pass something like dk0
 anyway, as the action applied (as-is) would be submitted against the
 wedge device, not the vnd, meaning
 VNDIOCCLR: Inappropriate ioctl for device
 would be encountered instead.
 
 It would need to walk backwards from the mounted structure to find the
 vnd that originally made it available. (And only unconfigure if there
 are no other mount points in use, of course.)
 
 Dave