aboutsummaryrefslogtreecommitdiff
path: root/tests/sys/fs
Commit message (Collapse)AuthorAgeFilesLines
* tarfs: Fix support for large filesDag-Erling Smørgrav2025-11-121-0/+27
| | | | | | | | | | | | | | | | | | | | * When fast-forwarding through a zstd frame, we incorrectly used the min() inline function instead of the MIN() macro. The function truncates the result to unsigned int, resulting in a decompression error when trying to seek more than 4 GB into the frame. * POSIX states that a size extended header record overrides the size field in the header if present, and that one must be included if the size of the file exceeds 8 GB (the size field maxes out at 64 GB). * Reduce repetition in the exthdr parser by deduplicating the syntax error handler. MFC after: 1 week Sponsored by: Klara, Inc. Fixes: 69d94f4c7608 ("Add tarfs, a filesystem backed by tarballs.") Reviewed by: allanjude Differential Revision: https://reviews.freebsd.org/D53718
* fusefs: standardize on OPNOTSUPP for posix_fallocate(2)Kyle Evans2025-11-051-8/+8
| | | | | | | | | | POSIX Issue 7 had allowed EINVAL for this case, but issue 8 moves it to ENOTSUP instead. ZFS uses the latter and we have some software in ports already that's wanting to use that to detect the filesystem not supporting it, so let's standardize on it. Reviewed by: imp (previous version), asomers, kib Differential Revision: https://reviews.freebsd.org/D53535
* fusefs: respect the server's FUSE_SETXATTR_EXT flagAlan Somers2025-11-031-15/+52
| | | | | | | | | | | | FUSE protocol 7.33 extended the FUSE_SETXATTR request format. But the extension is optional. The server must opt-in by setting the FUSE_SETXATTR_IN flag during FUSE_INIT. We were wrongly using the extended format for any server using protocol 7.33 or later. PR: 290547 Co-authored-by: CismonX <admin@cismon.net> Fixes: d5e3cf41e89 ("fusefs: Upgrade FUSE protocol to version 7.33") MFC after: 3 days
* fusefs: Fix intermittency in the BadServer.ShortWrite test caseAlan Somers2025-10-273-6/+10
| | | | | | | | | | | | | | | We were using the m_quit bit for two similar but distinct uses: * To instruct the server to quit * To cope with the kernel forcibly unmounting the fs Fix the intermittent test failure by adding a separate bit, m_expect_unmount, to handle cases like the latter. Reported by: Siva Mahadevan <me@svmhdvn.name> MFC after: 1 week Revied by: Siva Mahadevan <me@svmhdvn.name> Differential Revision: https://reviews.freebsd.org/D53357
* fusefs: fix page fault triggered by async notification when unmountedAlan Somers2025-10-263-2/+62
| | | | | | | | | | | | A FUSE daemon can send asynchronous notification to the kernel in order to, for example, invalidate an inode's cache. Fix a page fault that can happen if the file system isn't yet mounted, or is already unmounted, when that notification arrives. PR: 290519 MFC after: 1 week Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D53356
* fusefs: add a regression test for a cluster_read bugAlan Somers2025-10-231-0/+87
| | | | | | | | | | | | | | | VOP_BMAP is purely advisory. If VOP_BMAP returns an error during readahead, cluster_read should still succeed, because the actual data was still read just fine. Add a regression test for PR 264196, wherein cluster_read would fail if VOP_BMAP did. PR: 264196 MFC with: 62aef3f73f38db9fb68bffc12cc8900fecd58f0e Reported by: danfe Reviewed by: arrowd Differential Revision: https://reviews.freebsd.org/D51316
* fusefs: fix intermittency in the BadServer.ShortWrite testAlan Somers2025-10-141-0/+5
| | | | | | | | | | | | | | | This test implicitly depended on the order in which two threads completed. If the test thread finished first, the test would pass. But if the mock file system thread did, it would attempt to read from an unmounted file system, and fail. As a result, the test would randomly fail once out of every several thousand executions. Fix it by telling the mock file system's event loop to exit without attempting to read any more events. Reported by: Siva Mahadevan <me@svmhdvn.name> MFC after: 1 week Reviewed by: Siva Mahadevan <me@svmhdvn.name> Differential Revision: https://reviews.freebsd.org/D53080
* tarfs: Simplify sameness checksDag-Erling Smørgrav2025-10-071-3/+3
| | | | | | Sponsored by: Klara, Inc. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D52928
* fusefs: fix a kernel panic regarding SCM_RIGHTSAlan Somers2025-09-192-0/+127
| | | | | | | | | | | | | | | | | | If the last copy of an open file resides within the socket buffer of a unix-domain socket, then VOP_CLOSE will be called with no thread information. Fix fusefs to handle that case, and add a regression test. Also add a test case for writes to a file that lies within a sockbuf. Along with close, a write from the writeback cache is the only other operation I can think of that might apply to a file residing in a sockbuf. PR: 289686 Reported by: iron.udjin@gmail.com MFC after: 1 week Sponsored by: ConnectWise Reviewed by: glebius, markj Differential Revision: https://reviews.freebsd.org/D52625
* fusefs: fix the last_local_modify LLM/LastLocalModify.lookup/3 testAlan Somers2025-09-151-2/+10
| | | | | | | | | | | | | The LastLocalModify tests were originally written to simulate a race condition between VOP_SETATTR and VOP_LOOKUP. They were later extended to cover some other VOPs that can affect file size, including VOP_WRITE. However, the test never correctly simulated the race with VOP_WRITE. So that test only ever passed by accident. Fix it by always opening the file with O_DIRECT. PR: 289237 Reported by: Siva Mahadevan <me@svmhdvn.name> MFC after: 1 week
* fusefs: Fix a warning in a testWarner Losh2025-08-171-1/+1
| | | | | | | | ints can be up to 10 digits, plus NUL. Make the val array 12 to silences a lame gcc warning (the range of the int is such that we'll never truncate, but this is a cheap fix). Sponsored by: Netflix
* fusefs: don't fake the mountpoint's stat info before FUSE_INIT completesAlan Somers2025-08-051-0/+72
| | | | | | | | | | | | | | | Ever since the first GSoC contribution, fusefs has had a curious behavior. If the daemon hasn't finished responding to FUSE_INIT, fuse_vnop_getattr would reply to VOP_GETATTR requests for the mountpoint by returning all zeros. I don't know why. It isn't necessary for unmounting, even if the daemon is dead. Delete that behavior. Now VOP_GETATTR for the mountpoint will wait for the daemon to be ready, just like it will for any other vnode. Reported by: Vassili Tchersky Sponsored by: ConnectWise Differential Revision: https://reviews.freebsd.org/D50800
* fusefs: report that all tests require the fusefs kernel moduleAlan Somers2025-07-221-1/+2
| | | | | | | | | | | | | | | | | Previously the googletest tests would skip themselves if /dev/fuse could not be found. But that information would not be passed to Kyua. Instead it would think that they had passed. Also, the atf-sh test would previously fail if the fusefs module weren't loaded. Now both tests will correctly report their requirements to Kyua. Note that fusefs's googletest tests still require that the mac_bsdextended(4) module _not_ be loaded, but Kyua has no way to report such a requirement. MFC after: 2 weeks Sponsored by: ConnectWise Reviewed by: Siva Mahadevan <me@svmhdvn.name> Pull Request: https://github.com/freebsd/freebsd-src/pull/1782
* fusefs: Upgrade FUSE protocol to version 7.35.Claudiu I. Palincas2025-07-031-0/+30
| | | | | | | | | | | | Upgrade the FUSE API from protocol 7.33 to 7.35. Add support for FOPEN_NOFLUSH, introduced in 7.35. Also, reduce diffs vis-a-vis upstream by factoring out an ioctl type, a change missed in d5e3cf41e89. Signed-off-by: Claudiu I. Palincas <mscotty@protonmail.ch> Reviewed by: asomers Pull Request: https://github.com/freebsd/freebsd-src/pull/1744
* fusefs: fix a panic in vop_close with a CTL consumerAlan Somers2025-06-152-0/+74
| | | | | | | | | | | Kernel consumers like CTL may lack ucred objects. That led to a panic when CTL closed a fuse file, if atime was enabled on the mountpoint. Fix it by checking the ucred during close. PR: 283402 MFC after: 2 weeks Sponsored by: ConnectWise Differential Revision: https://reviews.freebsd.org/D48165
* fusefs: add more checks for buggy FUSE serversAlan Somers2025-06-133-3/+115
| | | | | | | | | | | | | | | | | * If a FUSE file system is NFS-exported (either by a kernel or userspace NFS server), then it must support FUSE_LOOKUP operations for ".". But if the response reports a different nodeid than the request, that's very bad. Fail the operation and warn the operator. * In general, a FUSE file may have a distinct "nodeid" and "inode number". But it the file system is NFS-exported (either by a kernel or userspace NFS server), then those two must match, because the NFS server will do VFS_VGET operations using the inode number. If they don't match, warn the operator. MFC after: 2 weeks Sponsored by: ConnectWise Differential Revision: https://reviews.freebsd.org/D48471
* fusefs: Fix a panic when unmounting before initAlan Somers2025-06-126-8/+176
| | | | | | | | | | | | | | fusefs would page fault due to the following sequence of events: * The server did not respond to FUSE_INIT in timely fashion. * Some other process tried to do unmount. * That other process got killed by a signal. * The server finally responded to FUSE_INIT. PR: 287438 MFC after: 2 weeks Sponsored by: ConnectWise Reviewed by: arrowd Differential Revision: https://reviews.freebsd.org/D50799
* fusefs: revert a workaround for a googletest bugAlan Somers2025-06-051-8/+1
| | | | | | | | | | This bug was fixed by googletest back in 2019 and released in googletest 1.10.0, I think. Using GTEST_SKIP from a test environment works now. https://github.com/google/googletest/issues/2189 MFC after: 2 weeks Sponsored by: ConnectWise
* atf, kyua: Implement require.kmods.Dag-Erling Smørgrav2025-05-311-1/+17
| | | | | | | | | | This adds a metadata variable, require.kmods, and corresponding functions or methods in C, C++, and shell, which allow a test to specify that it requires particular kernel modules to run. If the kernel modules are not present, the test is skipped. One might want to consider a kyua option which makes it attempt to load the modules instead. Differential Revision: https://reviews.freebsd.org/D47470
* fusefs: correct a comment in the testsAlan Somers2025-05-301-1/+1
| | | | | | | | | It's been wrong ever since the original commit in 2019. [skip ci] MFC after: 1 week Sponsored by: ConnectWise
* fusefs: Upgrade FUSE protocol to version 7.33.Claudiu I. Palincas2025-04-291-0/+48
| | | | | | | | | | | This commit upgrades the FUSE API to protocol 7.33, it doesn't implement any of protocol 7.33's new features, setxattr is tested for binary compatibility with protocol version 7.32. Update sys/fs/fuse/fuse_vnops.c Reviewed by: Alan Somers <asomers@FreeBSD.org> Pull Request: https://github.com/freebsd/freebsd-src/pull/1681
* Search for mntopts.h globally, not locallyBrooks Davis2025-04-223-5/+3
| | | | | | | | | Change the include directives to use <mntopts.h> instead of "mntopts.h" now that it's installed by libutil (the latter option was dubious regardless since a -I${SRCTOP}/sbin/mount was required anyway). Reviewed by: olce, imp, dim, emaste Differential Revision: https://reviews.freebsd.org/D49952
* Move mntopts(3) suppport into libutilBrooks Davis2025-04-221-4/+0
| | | | | | | | | | | | | | | | | Many programs use this functionality so it should be available centrally rather than compiled into each program independently. This has the modest downside of adding libutil dependencies to some mount_<foo> programs, but many (plus mount(8)) already have those depndencies so this shouldn't be a major imposition. In commit 906c312bbf74, Kirk said this could be done once the change was merged to FreeBSD 13. That happened in commit 668dfa016698 in 2023. While here perform related tidying including removing SRCS where the only entry is ${PROG}.c rendering it unnecessary. Reviewed by: olce, dim, emaste Differential Revision: https://reviews.freebsd.org/D49951
* fusefs tests: Use memcpy to work around a -Wstrlcpy-strlcast-size warningJohn Baldwin2025-04-111-1/+1
| | | | | | | | | | | | tests/sys/fs/fusefs/xattr.cc:572:50: error: size argument in 'strlcpy' call appears to be size of the source; expected the size of the destination [-Werror,-Wstrlcpy-strlcat-size] 572 | strlcpy((char*)out.body.bytes, attrs1, sizeof(attrs1)); | ~~~~~~~^~~~~~~ The warning is correct in that the size is the size of the source, but that is intended in this case. Use memcpy() instead of strlcpy() to match the same code in the size_only_race_smaller test above. Differential Revision: https://reviews.freebsd.org/D49786
* src: Use gnu++17 as the default C++ standardJohn Baldwin2025-04-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | Previously the compiler's default C++ standard was used unlike C where bsd.sys.mk explicitly sets a default language version. Setting an explicit default version will give a more uniform experience across different compilers and compiler versions. gnu++17 was chosen to match the default C standard. It is well supported by a wide range of clang (5+) and GCC (9+) versions. gnu++17 is also the default C++ standard in recent versions of clang (16+) and GCC (11+). As a result, many of the explicit CXXSTD settings in Makefiles had the effect of lowering the C++ standard instead of raising it as was originally intended and are removed. Note that the remaining explicit CXXSTD settings for atf and liblutok explicitly lower the standard to C++11 due to use of the deprecated auto_ptr<> template which is removed in later versions. Reviewed by: imp, asomers, dim, emaste Differential Revision: https://reviews.freebsd.org/D49223
* fusefs: fix the 32-bit build after 564c732b5c0Alan Somers2025-01-151-2/+2
| | | | | | | It's a printf format specifier again. MFC with: 564c732b5c0221373d067c9a21da09b310e676ae Sponsored by: ConnectWise
* fusefs: slightly better debugging in the testsAlan Somers2025-01-151-0/+4
| | | | | | | | If the kernel rejects a response written by the server, print it. That would most likely be due to an error in the test logic. MFC after: 2 weeks Sponsored by: ConnectWise
* fusefs: add a test for the max_read= mount optionAlan Somers2025-01-155-3/+72
| | | | | | | | | | When set, this limits the amount of data that the kernel will request of the server in any single read operation. The option has always been available in our fusefs implementation, but never covered by the test suite. MFC after: 2 weeks Sponsored by: ConnectWise
* fusefs: Coverity cleanup in the lseek testsAlan Somers2025-01-061-0/+11
| | | | | | | | | | Always check the return value of open(). Reported by: Coverity Scan CID: 1471118 1471133 1471215 1471896 1471901 1472116 1473799 CID: 1473879 1473996 1555269 1558044 MFC after: 2 weeks Sponsored by: ConnectWise
* fusefs: minor cleanup in the testsAlan Somers2025-01-064-6/+0
| | | | | | | Delete some unused includes and member variables. MFC after: 2 weeks Sponsored by: ConnectWise
* fusefs: minor refactor in the testsAlan Somers2024-12-241-18/+12
| | | | | | | Do more work in MockFS's constructor's member initializer list, instead of the body of the constructor. It's easier to read this way. Sponsored by: ConnectWise
* fusefs: fix a memory leakAlan Somers2024-12-231-0/+30
| | | | | | | | | Fix a leak of a fuse_ticket structure. The leak mostly affected NFS-exported fuse file systems, and was triggered by a failure during FUSE_LOOKUP. MFC after: 2 weeks Sponsored by: ConnectWise
* fusefs: ignore FUSE_NO_OPEN(DIR)_SUPPORT flagsCismonX2024-12-202-61/+4
| | | | | | | | | | | | | The FUSE_NO_OPEN_SUPPORT and FUSE_NO_OPENDIR_SUPPORT flags are only meant to indicate kernel features, and should be ignored if they appear in the FUSE_INIT reply flags. Also fix the corresponding test cases. MFC after: 2 weeks Reviewed by: Alan Somers <asomers@FreeBSD.org> Signed-off-by: CismonX <admin@cismon.net> Pull Request: https://github.com/freebsd/freebsd-src/pull/1509
* fusefs: delete a comment in the testsAlan Somers2024-12-181-1/+0
| | | | | | | | | | Even on a riscv embedded system, the fusefs tests run fast enough that 10 seconds is a reasonable timeout. [skip ci] MFC after: 2 weeks Sponsored by: ConnectWise
* fusefs: More accurately test the unique tokens in the test suiteAlan Somers2024-12-182-11/+10
| | | | | | | | | | | Every fuse ticket has a "unique" token. As the name implies, they're supposed to be unique. Previously the fusefs test suite verified their uniqueness by relying on the fact that they are also sequential. But they aren't guaranteed to be sequential. Enhance the tests by removing that convenient assumption. MFC after: 2 weeks Sponsored by: Axcient
* tests/sys/fs/fusefs: include iomanip headerEnji Cooper2024-10-201-0/+2
| | | | | | | | | | | io.cc relies on `std::setw(..)`, which is exported by the iomanip C++ header. Newer versions of GoogleTest don't export this header, so add the explicit include. This unbreaks the build with GoogleTest 1.15.2. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D47194
* fusefs: fix an uninitialized memory access in fuse_vnop_deallocateAlan Somers2024-09-081-0/+51
| | | | | | | | | | | | | If the FUSE_GETATTR issued to query a file's size during fuse_vnop_deallocate failed for any reason, then fuse_vnop_deallocate would attempt to destroy an uninitialized fuse_dispatcher struct, with a crash the likely result. This bug only affects FUSE file systems that implement FUSE_FALLOCATE, and is unlikely to be seen on those that don't disable attribute caching. Reported by: Coverity Scan CID: 1505308 MFC after: 2 weeks
* Remove "All Rights Reserved" from FreeBSD Foundation copyrightsEd Maste2024-07-301-1/+0
| | | | | | | These ones were unambiguous cases where the Foundation was the only listed copyright holder. Sponsored by: The FreeBSD Foundation
* Remove residual blank line at start of MakefileWarner Losh2024-07-154-4/+0
| | | | | | | This is a residual of the $FreeBSD$ removal. MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix
* man filesystems: fix more xrefs after move to s4Alexander Ziaee2024-06-283-3/+3
| | | | | | Fixes: 1a720cbec513 Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1282
* fusefs: fix two bugs regarding _PC_MIN_HOLE_SIZEAlan Somers2024-06-241-0/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Background: If a user does pathconf(_, _PC_MIN_HOLE_SIZE) on a fusefs file system, the kernel must actually issue a FUSE_LSEEK operation in order to determine whether the server supports it. We cache that result, so we only have to send FUSE_LSEEK the first time that _PC_MIN_HOLE_SIZE is requested on any given mountpoint. Problem 1: Unlike fpathconf, pathconf operates on files that may not be open. But FUSE_LSEEK requires the file to be open. As described in PR 278135, FUSE_LSEEK cannot be sent for unopened files, causing _PC_MIN_HOLE_size to wrongly report EINVAL. We never noticed that before because the fusefs test suite only uses fpathconf, not pathconf. Fix this bug by opening the file if necessary. Problem 2: On a completely sparse file, with no data blocks at all, FUSE_LSEEK with SEEK_DATA would fail to ENXIO. That's correct behavior, but fuse_vnop_pathconf wrongly interpreted that as "FUSE_LSEEK not supported". Fix the interpretation. PR: 278135 MFC after: 1 week Sponsored by: Axcient Differential Revision: https://reviews.freebsd.org/D44618
* fusefs: make the tests more robust to changes to maxphysAlan Somers2024-05-092-5/+14
| | | | | | | | Remove assumptions in two test cases that maxphys won't be huge. Reported by: kib MFC after: 2 weeks Sponsored by: Axcient
* tests/fusefs: fix all tests that depend on kern.maxphysGleb Smirnoff2024-05-065-17/+17
| | | | | | | | | The tests try to read kern.maxphys sysctl into int value, while unsigned long is required. Not sure when this was broken, seems like since cd8537910406e. Reviewed by: asomers Differential Revision: https://reviews.freebsd.org/D45053
* tarfs: Ignore global extended headers.Dag-Erling Smørgrav2024-04-031-0/+24
| | | | | | | | | | | | | | Previously, we would error out if we encountered a global extended header, because we don't know what it means. This doesn't really matter though, and traditionally, tar implementations have either ignored them or treated them as plain files, so just ignore them. This allows tarfs to mount tar files created by `git archive`. MFC after: 3 days Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D44600
* tarfs: Support paths that spill into exthdrs.Dag-Erling Smørgrav2024-04-031-0/+50
| | | | | | | | MFC after: 3 days Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D44599
* tarfs: Factor out common test code.Dag-Erling Smørgrav2024-03-061-26/+26
| | | | | | | | MFC after: 3 days Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Reviewed by: allanjude Differential Revision: https://reviews.freebsd.org/D44227
* tarfs: Fix checksum calculation.Dag-Erling Smørgrav2024-03-061-0/+22
| | | | | | | | | | | | | | The checksum code assumed that struct ustar_header filled an entire block and calculcated the checksum based on the size of the structure. The header is in fact only 500 bytes long while the checksum covers the entire block (“logical record” in POSIX terms). Add padding and an assertion, and clean up the checksum code. MFC after: 3 days Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44226
* tarfs: Fix two input validation issues.Dag-Erling Smørgrav2024-03-063-2/+196
| | | | | | | | | | | | | | | | | | | | | | | * Reject hard or soft links with an empty target path. Currently, a debugging kernel will hit an assertion in tarfs_lookup_path() while a non-debugging kernel will happily create a link to the mount root. * Use a temporary variable to store the result of the link target path, and copy it to tnp->other only once we have found it to be valid. Otherwise we error out after creating a reference to the target but before incrementing the target's reference count, which results in a use-after-free situation in the cleanup code. * Correctly return ENOENT from tarfs_lookup_path() if the requested path was not found and create_dirs is false. Luckily, existing callers did not rely solely on the return value. MFC after: 3 days PR: 277360 Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Reviewed by: sjg Differential Revision: https://reviews.freebsd.org/D44161
* fusefs: fix invalid value for st_birthtime.tv_nsecAlan Somers2024-02-042-12/+18
| | | | | | | | | | | | | | | | | | | | | | | | If a file system's on-disk format does not support st_birthtime, it isn't clear what value it should return in stat(2). Neither our man page nor the OpenGroup specifies. But our convention for UFS and msdosfs is to return { .tv_sec = -1, .tv_nsec = 0 }. fusefs is different. It returns { .tv_sec = -1, .tv_nsec = -1 }. It's done that ever since the initial import in SVN r241519. Most software apparently handles this just fine. It must, because we've had no complaints. But the Rust standard library will panic when reading such a timestamp during std::fs::metadata, even if the caller doesn't care about that particular value. That's a separate bug, and should be fixed. Change our invalid value to match msdosfs and ufs, pacifying the Rust standard library. PR: 276602 MFC after: 1 week Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D43590
* fusefs: fix some memory leaks in the testsAlan Somers2024-01-192-0/+3
| | | | MFC after: 2 weeks
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-14 13:05:23 +0000