kern/60135: fsid may not be unique

["imuwoto%gmail.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60135
>Category:       kern
>Synopsis:       fsid may not be unique
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 26 10:30:00 +0000 2026
>Originator:     YAMAMOTO Takashi
>Release:        -current
>Organization:
>Environment:
>Description:
netbsd f_fsidx (fsid_t)

traditional file systems backed by a single block device use
{dev_t, fstype} for their fsid, which should be sufficiently unique.

pseudo/network file systems use vfs_getnewfsid, which tries
to choose non-conflicting fsid dynamically.
it uses {makedev(fstype & 0xff,some number) + some other number, fstype}
this seems ok as far as fstype is unique.

zfs uses {(guid_high << 8) | 75, guid_low}, where guid is a 56-bit number,
which zfs ensures unique within zfs datasets. (grep unique_insert)
while very unlikely, nothing prevents it from conflicting with other
file systems.

btw, zfs put the lower 8-bits of makefstype() into its fsid. (75)
it doesn't make sense at all unless all file systems in the system
do the same as in solaris. also, because the hashing function used
by makefstype is very poor, the lower 8-bit can easily conflict.
(eg. ffs and kernfs share 139.)

---

statvfs f_fsid (long)

many of our file systems use the first word of fsid_t for this.
although our dev_t is 64-bit, it actually fits in a long because
we only use the lower 32-bit of dev_t.

this fsid might not be unique as (fstype & 0xff) can conflict with
a device major number.
for example, (makefstype("nfs") & 0xff) == 11, which conflicts
with block major of wd, ld, and st on some ports.
a possible fix: reserve a few major numbers for vfs_getnewfsid

zfs uses 56-bit fsid_guid for this. it's truncated on 32-bit ports.
this may conflict with other file systems.
a possible fix:
- make unique_insert ensure the uniqueness of truncated value
- possibly using /dev/zfs's major, generating a value which does never
  conflicts with makedev-based values other file systems use.

---

stat st_dev (dev_t)

it's a copy of vattr.va_fsid. many of file systems seem to use
the same value as the first word of f_fsidx. thus have same issues
as f_fsid.

zfs uses its f_fsid for this.
this may conflict with other file systems.

>How-To-Repeat:

>Fix: