aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ZTS: Remove FreeBSD 13.4-STABLETino Reichardt2024-10-062-16/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | Current CI is failing on FreeBSD 13.4-STABLE, because samba4 can't be installed there. Lets remove it for now. Update also the FreeBSD version definitions a bit. The naming is like this now: FreeBSD variants: - freebsd13-3r, freebsd13-4r, freebsd14-0r, freebsd14-1r (RELEASE) - freebsd13-4s, freebsd14-1s (STABLE) - freebsd15-0c (CURRENT) RHL based distros: - almalinux8, almalinux9, centos-stream9, fedora39, fedora40 Debian based: - debian11, debian12, ubuntu20, ubuntu22, ubuntu24 Misc Linux distros: - archlinux, tumbleweed Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Tino Reichardt <[email protected]> Closes #16610
* Update METAzfs-2.3.99Brian Behlendorf2024-10-041-2/+2
| | | | | | | | Increase the version to 2.3.99 to indicate the master branch is newer than the 2.3.x release. This ensures packages built from master branch are considered to be newer than the last release. Signed-off-by: Brian Behlendorf <[email protected]>
* Tag 2.3.0-rc1zfs-2.3.0-rc1Brian Behlendorf2024-10-041-2/+2
| | | | Signed-off-by: Brian Behlendorf <[email protected]>
* Update path for zed in zfs-zed.service for native debian packagesUmer Saleem2024-10-041-0/+1
| | | | | | Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Umer Saleem <[email protected]> Closes#15638
* Disable parallel build for native-deb* targetsUmer Saleem2024-10-041-0/+2
| | | | | | | | Running native-deb* targets in parallel via make is not supported. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Umer Saleem <[email protected]> Closes#14736
* Fix missing packaging files from release tarballsUmer Saleem2024-10-048-5/+55
| | | | | | | | | | Properly distribute files for native Debian packages. This fixes the issue with broken release tarballs. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Umer Saleem <[email protected]> Closes#15404 Closes#15586
* ZAP: Align za_name in zap_attribute_t to 8 bytesAlexander Motin2024-10-041-0/+1
| | | | | | | | | | | Our code reading/writing there may not handle misaligned accesses on a platforms that may care about it. I don't see a point to complicate it to satisfy UBSan in CI. This alignment costs nothing. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Alexander Motin <[email protected]> Sponsored by: iXsystems, Inc. Closes #15921 Closes #16606
* ARC: Cache arc_c value during arc_evict()Alexander Motin2024-10-041-7/+8
| | | | | | | | | | | | | | | Since arc_evict() run can take some time, arc_c change during it may result in undesired shift in ARC states balance. Primarily in case of arc_c reduction it may cause eviction from MFU data state despite its being below the target already. Instead we should evict as originally planned and if needed do another round after. Reviewed-by: Theera K. <[email protected]> Reviewed-by: George Melikov <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Alexander Motin <[email protected]> Sponsored by: iXsystems, Inc. Closes #16576 Closes #16605
* Defer resilver only when progress is above a thresholdPavel Snajdr2024-10-044-15/+57
| | | | | | | | | | | | | | | | | Restart a resilver from scratch, if the current one in progress is below a new tunable, zfs_resilver_defer_percent (defaulting to 10%). The original rationale for deferring additional resilvers, when there is already one in progress, was to help achieving data redundancy sooner for the data that gets scanned at the end of the resilver. But in case the admin wants to attach multiple disks to a single vdev, it wasn't immediately obvious the admin is supposed to run `zpool resilver` afterwards to reset the deferred resilvers and start a new one from scratch. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Pavel Snajdr <[email protected]> Closes #15810
* ZTS: Fix summary page creationTino Reichardt2024-10-031-0/+2
| | | | | | | | | | | | | There are cases, where some needed files for the summary page aren't created. Currently the whole Summary Page creation will fail then. Sample run: https://github.com/openzfs/zfs/actions/runs/11148248072/job/30999748588 Fix this, by properly checking for existence of the needed files. Reviewed-by: Tony Hutter <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Rob Norris <[email protected]> Signed-off-by: Tino Reichardt <[email protected]> Closes #16599
* Update compatibility.d filesBrian Behlendorf2024-10-022-1/+49
| | | | | | | | | | | | Add an openzfs-2.3 compatibility file for the next release. While there are no compatibility difference between Linux and FreeBSD for 2.3 symlinks for the -linux and -freebsd names are created for any scripts expecting that convention. Reviewed-by: Rob Norris <[email protected]> Reviewed-by: Tino Reichardt <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16588
* feature: large_microzapRob Norris2024-10-0216-22/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a4b21eadec we added the zap_micro_max_size tuneable to raise the size at which "micro" (single-block) ZAPs are upgraded to "fat" (multi-block) ZAPs. Before this, a microZAP was limited to 128KiB, which was the old largest block size. The side effect of raising the max size past 128KiB is that it be stored in a large block, requiring the large_blocks feature. Unfortunately, this means that a backup stream created without the --large-block (-L) flag to zfs send would split the microZAP block into smaller blocks and send those, as is normal behaviour for large blocks. This would be received correctly, but since microZAPs are limited to the first block in the object by definition, the entries in the later blocks would be inaccessible. For directory ZAPs, this gives the appearance of files being lost. This commit adds a feature flag, large_microzap, that must be enabled for microZAPs to grow beyond 128KiB, and which will be activated the first time that occurs. This feature is later checked when generating the stream and if active, the send operation will abort unless --large-block has also been requested. Changing the limit still requires zap_micro_max_size to be changed. The state of this flag effectively sets the upper value for this tuneable, that is, if the feature is disabled, the tuneable will be clamped to 128KiB. A stream flag is also added to ensure that the receiver also activates its own feature flag upon receiving the stream. This is not strictly necessary to _use_ the received microZAP, since it doesn't care how large its block is, but it is required to send the microZAP object on, otherwise the original problem occurs again. Because it's difficult to reliably distinguish a microZAP from a fatZAP from outside the ZAP code, and because it seems unlikely that most users are affected (a fairly niche tuneable combined with what should be an uncommon use of send), and for the sake of expediency, this change activates the feature the first time a microZAP grows to use a large block, and is never deactivated after that. This can be improved in the future. This commit changes nothing for existing pools that already have large microZAPs. The feature will not be retroactively applied, but will be activated the next time a microZAP grows past the limit. Don't use large_blocks feature for enable/disable tests. The large_microzap depends on large_blocks, so it gets enabled as a dependency, breaking the test. Instead use feature "longname", which has the exact same feature characteristics. Sponsored-by: Klara, Inc. Sponsored-by: Wasabi Technology, Inc. Reviewed-by: Allan Jude <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #16593
* Temporarily disable Direct IO by defaultBrian Behlendorf2024-10-021-1/+1
| | | | | | | | | While some remaining issues are resolved with the recently merged Direct IO functionality disable it by default. Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Brian Atkinson <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16597
* snapdir: add 'disabled' value to make .zfs inaccessibleBrian Behlendorf2024-10-0216-15/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some environments, just making the .zfs control dir hidden from sight might not be enough. In particular, the following scenarios might warrant not allowing access at all: - old snapshots with wrong permissions/ownership - old snapshots with exploitable setuid/setgid binaries - old snapshots with sensitive contents Introducing a new 'disabled' value that not only hides the control dir, but prevents access to its contents by returning ENOENT solves all of the above. The new property value takes advantage of 'iuv' semantics ("ignore unknown value") to automatically fall back to the old default value when a pool is accessed by an older version of ZFS that doesn't yet know about 'disabled' semantics. I think that technically the zfs_dirlook change is enough to prevent access, but preventing lookups and dir entries in an already opened .zfs handle might also be a good idea to prevent races when modifying the property at runtime. Add zfs_snapshot_no_setuid parameter to control whether automatically mounted snapshots have the setuid mount option set or not. this could be considered a partial fix for one of the scenarios mentioned in desired. Reviewed-by: Alexander Motin <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Tino Reichardt <[email protected]> Signed-off-by: Fabian Grünbichler <[email protected]> Co-authored-by: Fabian Grünbichler <[email protected]> Closes #3963 Closes #16587
* Avoid computing strlen() inside loopsrilysh2024-10-026-17/+28
| | | | | | | | | | | | | | | | Compiling with -O0 (no proper optimizations), strlen() call in loops for comparing the size, isn't being called/initialized before the actual loop gets started, which causes n-numbers of strlen() calls (as long as the string is). Keeping the length before entering in the loop is a good idea. On some places, even with -O2, both GCC and Clang can't recognize this pattern, which seem to happen in an array of char pointer. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: rilysh <[email protected]> Closes #16584
* Update all ABI filesBrian Behlendorf2024-10-014-45/+726
| | | | | | | Refresh all ABI files using the CI generated files as of commit 0cf14bf4b50e6be28198a517f1698f34da02a405. Signed-off-by: Brian Behlendorf <[email protected]> Closes #16592
* Linux 6.12: PG_error flag was removedRob Norris2024-10-014-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | torvalds/linux@09022bc196d2 removes the flag, and the corresponding SetPageError() and ClearPageError() macros, with no replacement offered. Going back through the upstream history, use of this flag has been gradually removed over the last year as part of the long tail of converting everything to folios. Interesting tidbit comments from torvalds/linux@29e9412b250e and torvalds/linux@420e05d0de18 suggest that this flag has not been used meaningfully since page writeback failures started being recorded in errseq_t instead (the whole "fsyncgate" thing, ~2017, around torvalds/linux@8ed1e46aaf1b). Given that, it's possible that since perhaps Linux 4.13 we haven't been getting anything by setting the flag. I don't know if that's true and/or if there's something we should be doing instead, but my gut feel is that its probably fine we only use the page cache as a proxy to allow mmap() to work, rather than backing IO with it. As such, I'm expecting that removing this will do no harm, but I'm leaving it in for older kernels to maintain status quo, and if there is an overall better way, that is left for a future change. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #16582
* Linux 6.12: f_version removed from struct fileRob Norris2024-10-013-0/+35
| | | | | | | | | | | | | | | | | | linux/torvalds@11068e0b64cb removes it, suggesting this was a always there as a helper to handle concurrent seeks, which all filesystems now handle themselves if necessary. Without looking into the mechanism, I can imagine how it might have been used, but we have always set it to zero and never read from it, presumably because we've always tracked per-caller position through the znode anyway. So I don't see how there can be any functional change for us by removing it. I've stayed conservative though and left it in for older kernels, since its clearly not hurting anything there. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #16582
* Linux 6.12: FMODE_UNSIGNED_OFFSET is now FOP_UNSIGNED_OFFSETRob Norris2024-10-011-0/+4
| | | | | | | | | | | | | | | | | | | | | torvalds/linux@641bb4394f40 asserts that this is a static flag, not intended to be variable per-file, so it moves it to file_operations instead. We just change our check to follow. No configure check is necessary because FOP_UNSIGNED_OFFSET didn't exist before this commit, and FMODE_UNSIGNED_OFFSET flag is removed in the same commit, so there's no chance of a conflict. It's not clear to me that we need this check at all, as we never set this flag on our own files, and I can't see any way that our llseek handler could recieve a file from another filesystem. But, the whole zpl_llseek() has a number of opportunities for pleasing cleanup that are nothing to do with this change, so I'll leave that for a future change. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #16582
* Linux 6.12: support 3arg dequeue_signal() without task paramRob Norris2024-10-012-15/+40
| | | | | | | | | | | | | See torvalds/linux@a2b80ce87a87. It claims the task arg is always `current`, and so it is with us, so this is a safe change to make. The only spanner is that we also support the older pre-5.17 3-arg dequeue_signal() which had different meaning, so we have to check the types to get the right one. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #16582
* Linux 6.12: avoid kmem_cache_create redefinitionRob Norris2024-10-011-0/+1
| | | | | | | | | | | | torvalds/linux@b2e7456b5c25 makes kmem_cache_create() a macro, which gets in the way of our our own redefinition, so we undef the macro first for our own clients. This follows what we did for kmem_cache_alloc(), see e951dba48. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #16582
* Support for longnames for files/directories (Linux part)Sanjeev Bagewadi2024-10-0141-400/+1233
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the ability for zfs to support file/dir name up to 1023 bytes. This number is chosen so we can support up to 255 4-byte characters. This new feature is represented by the new feature flag feature@longname. A new dataset property "longname" is also introduced to toggle longname support for each dataset individually. This property can be disabled, even if it contains longname files. In such case, new file cannot be created with longname but existing longname files can still be looked up. Note that, to my knowledge native Linux filesystems don't support name longer than 255 bytes. So there might be programs not able to work with longname. Note that NFS server may needs to use exportfs_get_name to reconnect dentries, and the buffer being passed is limit to NAME_MAX+1 (256). So NFS may not work when longname is enabled. Note, FreeBSD vfs layer imposes a limit of 255 name lengh, so even though we add code to support it here, it won't actually work. Reviewed-by: Tony Hutter <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Chunwei Chen <[email protected]> Closes #15921
* Allocate zap_attribute_t from kmem instead of stackSanjeev Bagewadi2024-10-0135-365/+513
| | | | | | | | | | | | This patch is preparatory work for long name feature. It changes all users of zap_attribute_t to allocate it from kmem instead of stack. It also make zap_attribute_t and zap_name_t structure variable length. Reviewed-by: Tony Hutter <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Chunwei Chen <[email protected]> Closes #15921
* Restrict raidz faulted vdev countDon Brady2024-10-014-11/+132
| | | | | | | | | | | Specifically, a child in a replacing vdev won't count when assessing the dtl during a vdev_fault() Sponsored-by: Klara, Inc. Sponsored-by: Wasabi Technology, Inc. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Tino Reichardt <[email protected]> Signed-off-by: Don Brady <[email protected]> Closes #16569
* send/recv: open up additional stream feature flagsRob Norris2024-10-011-34/+30
| | | | | | | | | | | | | | | | | | The docs for drr_versioninfo have marked the top 32 bits as "reserved" since its introduction (illumos/illumos-gate@9e69d7d). There's no indication of why they're reserved, so it seems uncontroversial to make a lot more flags available. I'm keeping the top eight reserved, and explicitly calling them out as such, so we can extend the header further in the future if we run out of flags or want to do some kind of change that isn't about feature flags. Sponsored-by: Klara, Inc. Sponsored-by: Wasabi Technology, Inc. Reviewed-by: Paul Dagnelie <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #15454
* Linux 6.11 compat: METABrian Behlendorf2024-09-301-1/+1
| | | | | | | Update the META file to reflect compatibility with the 6.11 kernel. Reviewed-by: Rob Norris <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16586
* lua: add flex array field to TString typeRob Norris2024-09-304-12/+15
| | | | | | | | | | | | | | | | | Linux 6.10+ with CONFIG_FORTIFY_SOURCE notices memcpy() accessing past the end of TString, because it has no indication that there there may be an additional allocation there. There's no appropriate upstream change for this (ancient) version of Lua, so this is the narrowest change I could come up with to add a flex array field to the end of TString to satisfy the check. It's loosely based on changes from lua/lua@ca41b43f and lua/lua@9514abc2. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Alexander Motin <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #16541 Closes #16583
* man: update recordsize max size infoGeorge Melikov2024-09-292-1/+17
| | | | | | | | | | | Reflect https://github.com/openzfs/zfs/commit/f2330bd1568489ae1fb16d975a5a9bcfe12ed219 change in our man pages and add some context. Wording is primarily copy-pasted from code comments. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Tino Reichardt <[email protected]> Signed-off-by: George Melikov <[email protected]> Closes #16581
* ZTS: Replace MD5 and SHA256 wit XXH128Tino Reichardt2024-09-2835-138/+117
| | | | | | | | | For data integrity checks as done in ZTS, the verification for unintended data corruption with xxhash128 should be a lot faster and perfectly usable. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Tino Reichardt <[email protected]> Closes #16577
* ZTS: Fix zpool_import_hostid_changed_unclean_exportBrian Behlendorf2024-09-281-5/+4
| | | | | | | | | | | Update the test case to freeze the pool then export it to better simulate a hard failure. This is preferable to copying the vdev while the pool's imported since with a copy we're not guaranteed the on-disk state will be consistent. That can in turn result in a pool import failure and a spurious test failure. Reviewed-by: Tino Reichardt <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16578
* zfs_log: add flex array fields to log record structsRob Norris2024-09-275-131/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ZIL log record structs (lr_XX_t) are frequently allocated with extra space after the struct to carry variable-sized "payload" items. Linux 6.10+ compiled with CONFIG_FORTIFY_SOURCE has been doing runtime bounds checking on memcpy() calls. Because these types had no indicator that they might use more space than their simple definition, __fortify_memcpy_chk will frequently complain about overruns eg: memcpy: detected field-spanning write (size 7) of single field "lr + 1" at zfs_log.c:425 (size 0) memcpy: detected field-spanning write (size 9) of single field "(char *)(lr + 1)" at zfs_log.c:593 (size 0) memcpy: detected field-spanning write (size 4) of single field "(char *)(lr + 1) + snamesize" at zfs_log.c:594 (size 0) memcpy: detected field-spanning write (size 7) of single field "lr + 1" at zfs_log.c:425 (size 0) memcpy: detected field-spanning write (size 9) of single field "(char *)(lr + 1)" at zfs_log.c:593 (size 0) memcpy: detected field-spanning write (size 4) of single field "(char *)(lr + 1) + snamesize" at zfs_log.c:594 (size 0) memcpy: detected field-spanning write (size 7) of single field "lr + 1" at zfs_log.c:425 (size 0) memcpy: detected field-spanning write (size 9) of single field "(char *)(lr + 1)" at zfs_log.c:593 (size 0) memcpy: detected field-spanning write (size 4) of single field "(char *)(lr + 1) + snamesize" at zfs_log.c:594 (size 0) To fix this, this commit adds flex array fields to all lr_XX_t structs that require them, and then uses those fields to access that end-of-struct area rather than more complicated casts and pointer addition. Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Alexander Motin <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #16501 Closes #16539
* ZTS: Update deadman_sync thresholdBrian Behlendorf2024-09-271-4/+4
| | | | | | | | | | | | Lower the minimum number of expected deadman events from 4 to 3. All that is strictly required is a single event to consider the test a pass. However, since I've never seen a count of less than 3 reported by the CI that should be sufficient. Reviewed-by: Alexander Motin <[email protected]> Reviewed-by: George Melikov <[email protected]> Reviewed-by: Tino Reichardt <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16575
* CI: Add logs to zloop workflowBrian Behlendorf2024-09-272-4/+16
| | | | | | | | | | | On failure attempt to include the most relevant portions of the ztest logs in the CI output. This full logs are still available for download but often a backtrace and the last output is enough. Install libunwind to improve the odds of a useful backtrace. Reviewed-by: Tino Reichardt <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16573
* ZTS: Fix zpool_import_hostid_changed_cachefile_unclean_exportBrian Behlendorf2024-09-261-6/+4
| | | | | | | | | | | Update the test case to freeze the pool then export it to better simulate a hard failure. This is preferable to copying the vdev while the pool's imported since with a copy we're not guaranteed the on-disk state will be consistent. That can in turn result in a pool import failure and a spurious test failure. Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16570
* Avoid BUG in migrate_folio_extratstabrawa2024-09-266-0/+140
| | | | | | | | | | | Linux page migration code won't wait for writeback to complete unless it needs to call release_folio. Call SetPagePrivate wherever PageUptodate is set and define .release_folio, to cause fallback_migrate_folio to wait for us. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: tstabrawa <[email protected]> Closes #15140 Closes #16568
* ZTS: Fix zpool_reguid Makefile.am and testsBrian Behlendorf2024-09-254-9/+7
| | | | | | | | | | | | | | | The zpool_reguid tests were not being included the dist tarball resulting in them not running. This is reported as a "failed verification" warning by the CI. Add the tests to the correct Makefile.am. Additionally, remove the usage of 'bc -e <expr>' from the tests. This option is only supported by the FreeBSD version of bc. Update the test case to reflect the 0 is not a valid GUID. Reviewed-by: Tino Reichardt <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16559
* CI: run only sanity check on limited OSes for nonbehavioral changesShengqi Chen2024-09-254-2/+150
| | | | | | | | | | | | | | | | | The commit uses heuristics to determine whether a PR is behavioral: It runs "quick" CI (i.e., only use sanity.run on fewer OSes) if (explicitly requested by user): - the *last* commit message contains a line 'ZFS-CI-Type: quick', or if (by heuristics): - the files changed are not in the list of specified directory, and - all commit messages does not contain 'ZFS-CI-Type: full'. It runs "full" CI otherwise. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Tino Reichardt <[email protected]> Signed-off-by: Shengqi Chen <[email protected]> Closes #16564
* Properly release key in spa_keystore_dsl_key_hold_dd()Alexander Motin2024-09-251-1/+1
| | | | | | | | | | | Since dsl_crypto_key_open() references the key, 0d23f5e2e4 should have called dsl_crypto_key_rele() to drop it first instead of calling dsl_crypto_key_free() directly. The final result should actually be the same, but without triggering dck_holds assertion. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Alexander Motin <[email protected]> Sponsored by: iXsystems, Inc. Closes #16567
* FreeBSD: Sync taskq_cancel_id() returns with LinuxAlexander Motin2024-09-241-2/+2
| | | | | | | | | | | Couple places in the code depend on 0 returned only if the task was actually cancelled. Doing otherwise could lead to extra references being dropped. The race could be small, but I believe CI hit it from time to time. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Alexander Motin <[email protected]> Sponsored by: iXsystems, Inc. Closes #16565
* Add missing guard defines for simd_statw0xel2024-09-241-0/+6
| | | | | | | | | This adds the HAVE_KERNEL_NEON and HAVE_KERNEL_FPU_INTERNAL guards to simd_stat.c defaulted to 0 to make it build again. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Shengqi Chen <[email protected]> Signed-off-by: Sebastian Wuerl <[email protected]> Closes #16558
* AUTHORS: refresh with recent new contributorsRob Norris2024-09-242-0/+5
| | | | | | | | | "I don't know half of you half as well as I should like; and I like less than half of you half as well as you deserve." Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rob Norris <[email protected]> Closes #16563
* CI: cancel workflows when PRs are updated (#16562)Brian Behlendorf2024-09-244-1/+16
| | | | | | | | | | | | | | | | For checkstyle, zloop, zfs-qemu, and codeql workflows cancel in-progress jobs when the PR is updated. Relevant GitHub Actions documentation: The following concurrency group cancels in-progress jobs or run on pull_request events only; if github.head_ref is undefined, the concurrency group will fallback to the run ID, which is guaranteed to be both unique and defined for the run. https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#example-using-a-fallback-value Signed-off-by: Brian Behlendorf <[email protected]> Closes #16562
* Evicting too many bytes from MFU metadataTheera K.2024-09-231-1/+1
| | | | | | | | | | | | Without updating 'm' we evict from MFU metadata all that we wanted to evict from all metadata, including already evicted MRU metadata ('m' is the total amount of metadata we had at the beginning, and 'w' is the total amount of metadata we want to have). Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Theera K. <[email protected]> Closes #16521 Closes #16546
* ZTS: CI Documentation UpdatesBrian Behlendorf2024-09-231-11/+4
| | | | | | | Update the CONTRIBUTING.md documentation to refer to the GitHub Actions workflows which have replaced the buildbot infrastructure. Signed-off-by: Brian Behlendorf <[email protected]> Closes #16561
* ZTS: CodeQL Action v3 updateBrian Behlendorf2024-09-231-3/+3
| | | | | | | | | | | | | | | Switch from v2 to v3 CodeQL Actions. The v2 actions will no longer be supported as of Dec '24 so we need to move to v3. According to the release notes they should be functionally equivalent. Note that the only difference between v2 and v3 of the CodeQL Action is the node version they support, ... For example 3.22.11 was the first v3 release and is functionally identical to 2.22.11. https://github.com/github/codeql-action/blob/main/CHANGELOG.md Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16560
* linux: log a scary warning when used with an experimental kernelRob Norris2024-09-231-0/+6
| | | | | | | | | | | | | Since the person using the kernel may not be the person who built it, show a warning at module load too, in case they aren't aware that it might be weird. Reviewed-by: Robert Evans <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Tony Hutter <[email protected]> Signed-off-by: Rob Norris <[email protected]> Sponsored-by: https://despairlabs.com/sponsor/ Closes #15986
* config/kernel: enforce maximum kernel version, with escape hatchRob Norris2024-09-233-2/+231
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | META lists the maximum kernel version we consider to be fully supported. However, we don't enforce this. Sometimes we ship experimental patches for a newer kernel than we're ready to support or, less often, we compile just fine against a newer kernel. Invariably, something doesn't quite work properly, and it's difficult for users to understand that they're actually running against a kernel that we're not yet ready to support. This commit tries to improve this situation. First, it simply enforces Linux-Maximum, by having configure bail out if you try to compile against a newer version that. Then, it adds the --enable-linux-experimental switch to configure. When supplied, this disables enforcing the maximum version, allowing the user to attempt to build against a kernel with version higher than Linux-Maximum. Finally, if the switch is supplied _and_ configure is run against a higher kernel version, it shows a big warning message when configure finishes, and defines HAVE_LINUX_EXPERIMENTAL for the build. This allows us to add code to modify runtime behaviour as well. Reviewed-by: Robert Evans <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Tony Hutter <[email protected]> Signed-off-by: Rob Norris <[email protected]> Sponsored-by: https://despairlabs.com/sponsor/ Closes #15986
* xattr dataset prop: change defaults to saGeorge Melikov2024-09-236-12/+14
| | | | | | | | | | | | | | | It's the main recommendation to set xattr=sa even in man pages, so let's set it by default. xattr=sa don't use feature flag, so in the worst case we'll have non-readable xattrs by other non-openzfs platforms. Non-overridden default `xattr` prop of existing pools will automatically use `sa` after this commit too. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: George Melikov <[email protected]> Closes #15147
* Fix /proc/spl/kstat/simd on x86Rich Ercolani2024-09-221-1/+9
| | | | | | | | Evidently while reworking it on aarch64, I broke it on x86 and didn't notice. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Rich Ercolani <[email protected]> Closes #16556
* ZTS: Add additional exceptionsBrian Behlendorf2024-09-221-0/+16
| | | | | | | | | | The following tests have been observed to occasionally fail when running under the CI. Updated our exceptions list to track them. Reviewed-by: Tino Reichardt <[email protected]> Reviewed-by: George Melikov <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #16553
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 08:52:05 +0000