Changes in cddl

Changes in cddl http://nxr.netbsd.org/rss/src/external/cddl/ en Copyright 2005 Java Adapt to thorpej@'s uvm_lwp_is_pagedaemon() change This is one step towards fixing the builds. Sun May 03 22:00:00 UTC 2026 kre osnet libuutil: Use mutex_init, not mutex_unlock, in child post-fork. Using mutex_unlock may try to wake a thread that doesn't exist in the child, which could lead to trouble such as crash or deadlock. But since the child is single-threaded, it is safe to just reinitialize the mutex memory anyway. PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock Tue Apr 28 13:00:00 UTC 2026 riastradh zfs: port a fix for data corruption issue from illumos see https://www.illumos.org/issues/17734 for the details. note: i didn't bother to patch illumos/freebsd code in our tree. the original commit message: > commit f6559a18843abdfa5849b9e74f239f9bd15796d3 > Author: Andy Fiddaman <illumos@fiddaman.net> > Date: Mon Nov 10 22:52:05 2025 +0000 > > 17734 ZFS fsync can trigger ZIL transaction reordering and data corruption > Portions contributed by: Alexander Motin <mav@FreeBSD.org> > Reviewed by: Ryan Zezeski <ryan@zinascii.com> > Reviewed by: Toomas Soome <tsoome@me.com> > Approved by: Dan McDonald <danmcd@edgecast.io> a review request on tech-kern: https://mail-index.netbsd.org/tech-kern/2026/03/04/msg030862.html Fri Mar 27 14:00:00 UTC 2026 yamt 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 Fri Mar 27 13:00:00 UTC 2026 yamt zfs: fix "slow rm" issue (cont.) commit a change which was lost during a porting from my local git repo to cvs. fortunately, it was harmless to miss this change though. Mon Mar 23 23:00:00 UTC 2026 yamt zfs: fix "slow rm" issue * stop commiting zil in zfs_netbsd_reclaim and other operations in vnode reclaim path. * retire zfs_zget_cleaner/VN_RELE_CLEANER. instead, just use normal zfs_zget and vrele_async. note that these two changes depend on each other: * zfs_zget_cleaner relies on zil_commit in zfs_netbsd_reclaim to ensure that the znode referenced by TX_WRITE itx is always in-core. * otoh, zfs_zget_clear makes zil_commit in the vnode reclaim path possible. that is, zfs_netbsd_reclaim (VOP_RECLAIM) is called with the vnode in VS_RECLAIMING state, which would make vcache_vget block. if the vnode being reclaimed happened to have TX_WRITE itx on the zil, it deadlocks. an alternative would be to make the upper layer (vfs_vnode.c) retain unlinked vnodes for a while. (a bit longer than the 5 sec txg commit interval should be enough.) eg. by making zfs_netbsd_inactive report a_recycle = 0. but i guess it's better to remove zfs_zget_cleaner/VN_RELE_CLEANER to to keep the code less diverged from the upstream zfs. also, this commit makes zfs_umount retry vflush a bit. it's necessary because, for some reasons, during unmount, zil_close commits the log, which can load some referenced vnodes back to the cache. i don't understand why zil_close needs to commit the log when we are syncing txg for unmount anyway. although it might be possible to avoid the zil commit at all, probably this change is less invasive than that. this logic is partly from J. Hannken-Illjes. PR/59885 https://gnats.netbsd.org/59885 discussed on tech-kern. https://mail-index.netbsd.org/tech-kern/2026/02/20/msg030817.html Sun Mar 22 13:00:00 UTC 2026 yamt zpool_find_import_impl: fix block/character device confusion this commit fixes zpool import failure in some cases. the current logic sometimes (eg. "zpool import -d" with a directory which is not "/dev") ends up with picking character devices and pass them to ZFS_IOC_POOL_TRYIMPORT/ZFS_IOC_POOL_IMPORT ioctl. such attempts would fail, marking the corrosponding vdevs UNAVAIL. this commit fixes it by skipping character devices. also, this commit makes the label checking logic prefer to use character devices when available because it seems like the intention of the upstream logic. also, this commit fixes import of file-backed vdevs. Fri Mar 20 00:00:00 UTC 2026 yamt zfs: fix zfs_range_lock_try the change "zfs: add zfs_range_lock_try" was incomplete. i've observed the following deadlock: ``` db{0}> tr /a ffff96777f74f400 trace: pid 0 lid 125 at 0xffffce80c3203b50 sleepq_block() at netbsd:sleepq_block+0xf4 cv_wait() at netbsd:cv_wait+0xca pool_grow() at netbsd:pool_grow+0x47b pool_get() at netbsd:pool_get+0xae pool_cache_get_slow() at netbsd:pool_cache_get_slow+0x136 pool_cache_get_paddr() at netbsd:pool_cache_get_paddr+0x27d kmem_intr_alloc() at netbsd:kmem_intr_alloc+0x13c kmem_alloc() at netbsd:kmem_alloc+0x2a zfs_range_lock_impl() at zfs:zfs_range_lock_impl+0x30 zfs_netbsd_putpages() at zfs:zfs_netbsd_putpages+0x1c0 VOP_PUTPAGES() at netbsd:VOP_PUTPAGES+0x43 uvm_pageout() at netbsd:uvm_pageout+0x257 db{0}> ``` this commit fixes it by using KM_NOSLEEP when non-blocking operation is requested. Mon Mar 16 14:00:00 UTC 2026 yamt solaris vfs_optionisset: treat 0 as unspecified this allows users to leave it default. before this change, when a user runs "zfs mount -a", it was processed as "mount them read-write, overriding readonly property". i don't think it's what the user usually intends. looking at the illumos code, it seems that mount options there are basically tri-state. that is, "ro", "rw", and unspecified. as NetBSD only has a single bit, MNT_RDONLY or !MNT_RDONLY, this commit maps !MNT_RDONLY to unspecified, which i believe more often matches the user's intention. it also seems like what illumos does for the legacy MS_RDONLY bit if i read their code correctly. that is, if MS_RDONLY is set, it sets MNTOPT_RO. on the other hand, a lack of MS_RDONLY doesn't imply MNTOPT_RW. references: "Temporary Mount Point Properties" section of zfs(8) PR/60024 https://gnats.netbsd.org/60024 Sun Mar 01 13:00:00 UTC 2026 yamt zfs: add zfs_range_lock_try i plan to use this to fix pgdaemon deadlock issue. (PR/60004) (thus i didn't bother to implement RL_READER.) note: recent openzfs has a similar function. (zfs_rangelock_tryenter) this commit ought to be reverted when/if we switch to it. https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=60004 Fri Feb 20 08:00:00 UTC 2026 yamt dtrace_sdt: Don't ignore the first stack frame in sdt probes. The aframes argument to dtrace_probe_create gives the number of stack frames that are ignored in stack(), the first frame of which is `caller'. This is for, e.g., profiler interrupts where the interrupt frame itself isn't interesting; it's the code that was interrupted that was interesting (hence profile_aframes = PROF_ARTIFICIAL_FRAMES is often nonzero, or even several frames deep). But for sdt, the direct caller is the interesting part -- when we have something like: foo() { ... bar(); ... } bar() { ... SDT_PROBE1(...); ... } We want `caller' to be the return address in bar of SDT_PROBE1(...), not the return address in foo of bar(). PR kern/59934: dtrace_sdt: caller is off by a frame Thu Jan 22 04:00:00 UTC 2026 riastradh execsnoop: remove -J and trailing whitespace -J is for jails, since this comes from FreeBSD; however it broke -a|-A. Sun Jan 11 22:00:00 UTC 2026 wiz dtrace: sprinkle #include <sys/endian.h> Sat Jan 10 17:00:00 UTC 2026 nia use <sys/endian.h> until I get this to play with rump builds Sat Jan 10 17:00:00 UTC 2026 nia nvpair: sprinkle #include <sys/endian.h> Sat Jan 10 16:00:00 UTC 2026 nia osnet: Sprinkle <sys/endian.h> inclusion. prompted by PR pkg/59839 Wed Jan 07 08:00:00 UTC 2026 nia Fix various typos in comments. Thu Dec 11 07:00:00 UTC 2025 andvar Allow code to include either (or both) of <sys/elfdefinitions.h> and <sys/exec_elf.h>, in any order. This is a work-around to address PR lib/59564 (build breakage when both of these files are #included). With this changeset, whichever file gets included first 'wins'. Prior changes in NetBSD and upstream at Elftoolchain have aligned the 'generic' ELF definitions in NetBSD's <sys/exec_elf.h> with those in Elftoolchain's <sys/elfdefinitions.h>, so that either file can be used interchangeably when building NetBSD. This changeset also removes prior workarounds in the source tree for this issue. PR lib/59564 Tue Nov 18 13:00:00 UTC 2025 jkoshy ctfconvert: supply more HAVE_NBTOOL_CONFIG_H PR toolchain/59659 Fri Sep 19 01:00:00 UTC 2025 ozaki-r PR/59659: Ryota Ozaki: Make the tool version behave the same way as the native. Thu Sep 18 13:00:00 UTC 2025 christos