NetBSD Problem Report #60135

From www@netbsd.org  Thu Mar 26 10:26:29 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R12" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D1A501A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 26 Mar 2026 10:26:29 +0000 (UTC)
Message-Id: <20260326102628.962751A923D@mollari.NetBSD.org>
Date: Thu, 26 Mar 2026 10:26:28 +0000 (UTC)
From: imuwoto@gmail.com
Reply-To: imuwoto@gmail.com
To: gnats-bugs@NetBSD.org
Subject: fsid may not be unique
X-Send-Pr-Version: www-1.0
X-From4GNATS: "imuwoto@gmail.com via gnats" <gnats-admin@NetBSD.org>

>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
>Last-Modified:  Fri Mar 27 23:45:01 +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:

>Audit-Trail:
From: "YAMAMOTO Takashi" <yamt@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60135 CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Date: Fri, 27 Mar 2026 13:50:52 +0000

 Module Name:	src
 Committed By:	yamt
 Date:		Fri Mar 27 13:50:52 UTC 2026

 Modified Files:
 	src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vfsops.c
 	    zfs_vnops.c

 Log Message:
 zfs: use 32-bit st_dev for stat(2)

 while dev_t is 64-bit on NetBSD since the merge of
 christos-time_t branch in 2009, we only use the lower
 32-bit of it, at least for the purpose of specifying
 a device in the kernel.

 however, dev_t is also used as a file system id. eg. st_dev
 reported by stat(2). as zfs has no device to naturally represent
 its file system, currently it reports 56-bit guid of the file
 system for the purpose.

 unfortunately, some user applications still consider it as
 a good old device id and assumes operations like
 makedev(major(dev),minor(dev)) preserves the value.
 it doesn't hold for NetBSD's implementation of makedev and
 friends, which only honors the lower 32-bit of the dev_t.

 this commit makes zfs report fsid with the high 32-bit zeros
 to avoid the issues in such applications. namely, this fixes an
 issue with rsync, reported by HIROSE yuuji on a japanese ML [1]
 in 2024. you can find his reproduce recipe below. i was able to
 reproduce the issue with rsync-3.4.1 from pkgsrc.

 maybe we can "fix" our, at least userland-visible version of,
 makedev and friends to provide full 64-bit round-trip as some
 of other platforms do. (eg. glibc, freebsd)
 although it might be an improvement and can benefit other things
 like nfs v3, it isn't an alternative to this fix because it
 doesn't fix existing application binaries built with the current
 version of the macros.

 note: this commit also changes statvfs f_fsid. as f_fsid is a long,
 before this change, we were truncating the value only on 32-bit ports.

 note: this commit doesn't change the "netbsd-extended" fsid
 (f_fsidx), which is used for nfs file handles.

 note: this commit would cause a flag day for applications which
 somehow save st_dev of files. are there such applications?

 note: this commit would increase the chance of fsid conflicts.
 currently zfs ensures its fsids unique within zfs, but not with
 other netbsd file systems. with this commit, there can be conflict
 even within zfs. (mentioned in PR/60135)

 ```
 rm -rf src
 rm -rf dest
 mkdir -p src/a/b/c
 mkdir -p src/1/2/3
 mkdir dest
 rsync -avx --delete src dest
 rm -r src/1
 rsync -avx --delete src dest
 test -d dest/src/1 && echo "this directory should have been removed"
 ```

 [1] http://www.re.soum.co.jp/~jun/welcome.html#netbsd

 related to PR/60135
 https://gnats.netbsd.org/60135


 To generate a diff of this commit:
 cvs rdiff -u -r1.34 -r1.35 \
     src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vfsops.c
 cvs rdiff -u -r1.97 -r1.98 \
     src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "YAMAMOTO Takashi" <yamt@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60135 CVS commit: src/sys/kern
Date: Fri, 27 Mar 2026 23:43:13 +0000

 Module Name:	src
 Committed By:	yamt
 Date:		Fri Mar 27 23:43:13 UTC 2026

 Modified Files:
 	src/sys/kern: vfs_init.c

 Log Message:
 vfs_attach: reject file system with non-unique fstype

 while currently our fstype values are still unique, given the poor
 hash function used by makefstype [1], it isn't too unlikely for a future
 or out-of-tree file system to have a conflicting value. it's safer
 to reject it explicitly. note that, we can't lightly change the hash
 function because it's exposed as a part of nfs file handles.

 [1] for example, makefstype("qa") == makefstype("uq") == 0x1a5.

 the current list of fstype values used by the in-tree file systems:

     0000064b zfs
     000006a6 udf
     0000070b nfs
     0000072b lfs
     0000073b mfs
     0000076b hfs
     0000078b ffs
     000007bb efs
     000007fb afs
     00001a64 umap
     00001d0c null
     00001d2b ntfs
     00001f1b v7fs
     00001fc1 coda
     000069ab tmpfs
     000069c2 union
     00006acb puffs
     00006b7b ptyfs
     00006f8b smbfs
     0000736b nilfs
     0000764f msdos
     000078ff fdesc
     0001a0ab rumpfs
     0001ae1b procfs
     0001d28b kernfs
     0001e5c8 cd9660
     0001eb1b autofs
     0001f3cb ext2fs
     0001fd1b adosfs
     0006bd4b sysvbfs
     000756bd overlay
     001eda9d filecore

 related to PR/60135
 https://gnats.netbsd.org/60135


 To generate a diff of this commit:
 cvs rdiff -u -r1.67 -r1.68 src/sys/kern/vfs_init.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Home	PR Database Search