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
[28 lines not shown]
lint: in case of lossy floating point conversions, print exact value
When running lint on sparc64 with target sparc64, some tests print
warnings in cases where they shouldn't. To track down their cause,
print the exact floating point value in the message, in hexadecimal.
As the snprintf(3) manual page says, there are multiple equivalent
representations, so just match them using the placeholder "....." in the
"expect" comments. In this particular case, the message is missing
completely, so the output of the failed test will reveal the actual
value.
The affected test cases are:
* msg_380.c:38, converting -9223372036854775809.0 to 'long long'
* msg_380.c:39, converting -9223372036854775808.0 to 'long long'
* msg_381.c:38, converting -9223372036854775809.0 to 'long long'
* msg_381.c:39, converting -9223372036854775808.0 to 'long long'
Add a new land_mine test case
This new test case is intended to attempt to find buried
shell expansion code bugs, that don't often affect normal
scripts, (including most of the normal ATF tests) but can
cause problems with very odd ones.
It would have detected the bug introduced last Monday which
blew up the gettext libtool usage (because of clearly unintentional
libtool script code), which was fixed on Thursday.
It also would have detected a similar one, which was never
detected in the wild, which was installed in 2019, and also
fixed on Thursday.
Whether it can detect other similar problems in other cases is
unknown - probably not, until they are understood... More sub-tests
here for more bizarre cases might help, or might not.
[6 lines not shown]
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 at 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 at FreeBSD.org>
> Reviewed by: Ryan Zezeski <ryan at zinascii.com>
> Reviewed by: Toomas Soome <tsoome at me.com>
> Approved by: Dan McDonald <danmcd at edgecast.io>
a review request on tech-kern:
https://mail-index.netbsd.org/tech-kern/2026/03/04/msg030862.html
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
[43 lines not shown]
Add some tests for an ancient NetBSD sh bug
This adds 78 sub-tests to the t_expand:alternative test-case.
In old NetBSD shells - which means anything from May 1994 (when CSRG
BSD 4.4 lite was merged into NetBSD) until (early hours UTC) 26 Mar 2026,
12 of these new 78 sub-tests would fail.
The issue being tested here was fixed about 32 hours ago, along with the
completely unrelated fix for the recently introduced land mine off by one bug.
All these new sub-tests will pass in a /bin/sh from HEAD now.
No other shell I have to test (except bosh) fails any of these added
78 sub-tests (and bosh, which also fails plenty of the existing ones, fails
less of the new ones than the NetBSD sh did - and different sub-tests).
Of course, since I am adding tests to deliberately provoke what I already
knew from reading the source would fail in our shell, that is perhaps an
unfair comparison.
[11 lines not shown]
Learn how to add (me that is).
This is a NFC change - just correcting the sub-test numbers in the
comments (somehow, sometime in the past, I deduced that 79 + 3 == 80,
and from that point onwards, everything was out by two).
The tests themselves count properly, the comments are intended to allow
matching the failing sub-test number reported when something fails, with
the code for the failing sub-test in the source. Having the wrong values
listed wouldn't help with that. Of course, as this simple test case
doesn't fail, it was never noticed that the numbering was incorrect.
fix swap encryption data corruption issue
when paging out, uvm_swap_io encrypts the page contents in-place
and then issues write requests to swapdev. if the write fails
for some reason, the pageout will be cancelled. but it leaves
the data in the pages encrypted. ie. data corruption. note that
this doesn't necessarily involve broken swap devices. as we are
in the pagedaemon context, some kind of transient errors are
rather normal. for example, ffs VOP_BMAP has special cases for
the pagedaemon to return ENOMEM.
this commit fixes the issue by simply reverting the encryption
on error.
PR/60082https://gnats.netbsd.org/60082
simplify swap encryption a bit
* disallow changes of vm.swap_encrypt sysctl when any swap
is configured. note: this doesn't affect the ability to
set it in /etc/sysctl.conf because /etc/rc.d/sysctl is
executed before /etc/rc.d/swap1.
* retire per-page encryption tracking. (swd_encmap)
from now on, the whole swap is encrypted or not.
PR/60084https://gnats.netbsd.org/60084
genmatch.cc: bring across several enhancements from mainline GCC.
in my testing this reduces the size of the emitted "gimple-match.cc"
by about 35%, reduces the code section sise about 15%, and reduces
the compile time about 30%. (this file is the largest single compile
for all of GCC.)
this makes it capable of compiling on vax and sparc again, it seems,
where both were already capable for GCC 14 (which in addition to this
set, splits the emitted file into 10 sub parts for compiling both
separately and in parallel.)
(this is part 1, part 2 will be about mergig the split of the output
into multiple files, but may be abandoned as this portion helps
enough.)
tested on amd64, vax, sparc as only target, powerpc, with some arm64,
arm, and m68k to come -- may be also very useful for m68k target.
[29 lines not shown]
Streamline pre-main() prologue just a bit:
- Enable the on-chip caches for 68020 and 68030 in the MMU-enablement
code fragment, as is already done for 68040 and 68060. Eliminates
a bunch of duplicated code in each locore.s.
- The ATC (and the HP MMU TLB, if applicable) has already been flushed /
invalidated as part of enabling the MMU, so there's no need to either
call _TIBA() or perform an inline pflusha again after the MMU has been
turned on.
zfs: put back deferred atime update to VOP_INACTIVE
we currently push atime updates in VOP_RECLAIM and VFS_SYNC.
VFS_SYNC iterates all cached vnodes for that:
> /*
> * On NetBSD, we need to push out atime updates. Solaris does
> * this during VOP_INACTIVE, but that does not work well with the
> * BSD VFS, so we do it in batch here.
> */
it isn't ideal for systems with large vnode cache.
i'm not sure why it "does not work well with the BSD VFS" either.
maybe historical reasons which don't hold anymore?
this commit put the atime pushing logic to VOP_INACTIVE, where
it's done in solaris and freebsd. it seems working well as far as
i tested.
[7 lines not shown]
