aboutsummaryrefslogtreecommitdiff
path: root/tests/sys/fs/fusefs/mockfs.cc
Commit message (Collapse)AuthorAgeFilesLines
* fusefs: Fix intermittency in the BadServer.ShortWrite test caseAlan Somers2025-10-271-2/+3
| | | | | | | | | | | | | | | 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-261-1/+3
| | | | | | | | | | | | 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: 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: Fix a panic when unmounting before initAlan Somers2025-06-121-6/+12
| | | | | | | | | | | | | | 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
* Search for mntopts.h globally, not locallyBrooks Davis2025-04-221-2/+1
| | | | | | | | | 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
* 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-151-1/+9
| | | | | | | | | | 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: 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: More accurately test the unique tokens in the test suiteAlan Somers2024-12-181-9/+6
| | | | | | | | | | | 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
* fusefs: fix some memory leaks in the testsAlan Somers2024-01-191-0/+1
| | | | MFC after: 2 weeks
* Remove $FreeBSD$: two-line .h patternWarner Losh2023-08-161-2/+0
| | | | Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
* spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSDWarner Losh2023-05-121-1/+1
| | | | | | | | | The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
* fusefs: add some more test cases for bad fuse serversAlan Somers2023-02-221-4/+2
| | | | | | | MFC after: 1 week Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D38719
* fusefs: fix VOP_ADVLOCK with SEEK_ENDAlan Somers2022-10-191-1/+13
| | | | | | | | | | | When the user specifies SEEK_END, unlike SEEK_CUR, VOP_ADVLOCK must adjust lock offsets itself. Sort-of related to bug 266886. MFC after: 2 weeks Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D37040
* fusefs: use the fsname mount option if setAlan Somers2022-04-291-1/+5
| | | | | | | | | | The daemon can specify fsname=XXX in its mount options. If so, the file system should report f_mntfromname as XXX during statfs. This will show up in the output of commands like mount and df. Submitted by: Ali Abdallah <ali.abdallah@suse.com> MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D35090
* fusefs: add a test for the subtype= optionAlan Somers2022-04-291-1/+6
| | | | | | | | | At mount time server can set, for example, "subtype=xfs", so that mount(8) will later show the mountpoint's file system as "fusefs.xfs". fusefs has had this feature ever since the original GSoC commit in 2012, but there's never been a test for it. MFC after: 2 weeks
* fusefs: validate servers' error valuesAlan Somers2022-04-151-1/+8
| | | | | | | | | | | | | | | | | Formerly fusefs would pass up the stack any error value returned by the fuse server. However, some values aren't valid for userland, but have special meanings within the kernel. One of these, EJUSTRETURN, could cause a kernel page fault if the server returned it in response to FUSE_LOOKUP. Fix by validating all errors returned by the server. Also, fix a data lifetime bug in the FUSE_DESTROY test. PR: 263220 Reported by: Robert Morris <rtm@lcs.mit.edu> MFC after: 3 weeks Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D34931
* fusefs: implement VOP_ALLOCATEAlan Somers2022-01-011-1/+12
| | | | | | | | | Now posix_fallocate will be correctly forwarded to fuse file system servers, for those that support it. MFC after: 2 weeks Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33389
* fusefs: better debugging for FUSE_RENAME in the testsAlan Somers2021-12-031-0/+9
| | | | MFC after: 2 weeks
* fusefs: update atime on reads when using cached attributesAlan Somers2021-11-291-1/+5
| | | | | | | | | | | | | | | When using cached attributes, whether or not the data cache is enabled, fusefs must update a file's atime whenever it reads from it, so long as it wasn't mounted with -o noatime. Update it in-kernel, and flush it to the server on close or during the next setattr operation. The downside is that close() will now frequently trigger a FUSE_SETATTR upcall. But if you care about performance, you should be using -o noatime anyway. MFC after: 2 weeks Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33145
* fusefs: fix intermittency in the dev_fuse_poll testAlan Somers2021-10-061-3/+7
| | | | | | | | | | | | The DevFusePoll::access/select test would occasionally segfault. The cause was a file descriptor that was shared between two threads. The first thread would kill the second and close the file descriptor. But it was possible that the second would read the file descriptor before it shut down. That did not cause problems for kqueue, poll, or blocking operation, but it triggered segfaults in select's macros. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D32142
* fusefs: ensure that FUSE ops' headers' unique values are actually uniqueAlan Somers2021-06-191-0/+9
| | | | | | | | | | | | | | | | | Every FUSE operation has a unique value in its header. As the name implies, these values are supposed to be unique among all outstanding operations. And since FUSE_INTERRUPT is asynchronous and racy, it is desirable that the unique values be unique among all operations that are "close in time". Ensure that they are actually unique by incrementing them whenever we reuse a fuse_dispatcher object, for example during fsync, write, and listextattr. PR: 244686 MFC after: 2 weeks Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D30810
* fusefs: also debug INIT operations in the test suiteAlan Somers2021-06-191-0/+2
| | | | | MFC after: 2 weeks Reviewed by: pfg
* fusefs: support EVFILT_WRITE on /dev/fuseAlan Somers2021-06-161-3/+17
| | | | | | | | | /dev/fuse is always ready for writing, so it's kind of dumb to poll it. But some applications do it anyway. Better to return ready than EINVAL. MFC after: 2 weeks Reviewed by: emaste, pfg Differential Revision: https://reviews.freebsd.org/D30784
* fusefs: implement FUSE_COPY_FILE_RANGE.Alan Somers2021-01-011-0/+20
| | | | | | | | | | This updates the FUSE protocol to 7.28, though most of the new features are optional and are not yet implemented. MFC after: 2 weeks Relnotes: yes Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D27818
* Fix i386 build following 37df9d3bba8577fcdd63382ff5a4a5cbb4aa55b4.Cy Schubert2021-01-011-3/+3
| | | | | MFC after: 2 weeks X-MFC with: 37df9d3bba8577fcdd63382ff5a4a5cbb4aa55b4
* fusefs: update FUSE protocol to 7.24 and implement FUSE_LSEEKAlan Somers2020-12-311-4/+31
| | | | | | | | | | FUSE_LSEEK reports holes on fuse file systems, and is used for example by bsdtar. MFC after: 2 weeks Relnotes: yes Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D27804
* fusefs: fix the tests for a wider range of maxphysAlan Somers2020-12-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | maxphys is now a tunable, ever since r368124. The default value is also larger than it used to be. That broke several fusefs tests that made assumptions about maxphys. * WriteCluster.clustering used the MAXPHYS compile-time constant. * WriteBackAsync.direct_io_partially_overlaps_cached_block implicitly depended on the default value of maxphys. Fix it by making the dependency explicit. * Write.write_large implicitly assumed that maxphys would be no more than twice maxbcachebuf. Fix it by explicitly setting m_max_write. * WriteCluster.clustering and several others failed because the MockFS module did not work for max_write > 128KB (which most tests would set when maxphys > 256KB). Limit max_write accordingly. This is the same as fusefs-libs's behavior. * Bmap's tests were originally written for MAXPHYS=128KB. With larger values, the simulated file size was too small. PR: 252096 Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D27769
* fusefs: Fix iosize for FUSE_WRITE in 7.8 compat modeAlan Somers2019-09-111-47/+82
| | | | | | | | | | | | | | | | | When communicating with a FUSE server that implements version 7.8 (or older) of the FUSE protocol, the FUSE_WRITE request structure is 16 bytes shorter than normal. The protocol version check wasn't applied universally, leading to an extra 16 bytes being sent to such servers. The extra bytes were allocated and bzero()d, so there was no information disclosure. Reviewed by: emaste MFC after: 3 days MFC-With: r350665 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21557 Notes: svn path=/head/; revision=352230
* fusefs: coverity cleanup in the testsAlan Somers2019-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Address the following defects reported by Coverity: * Structurally dead code (CID 1404366): set m_quit before FAIL, not after * Unchecked return value of sysctlbyname (CID 1404321) * Unchecked return value of stat(2) (CID 1404471) * Unchecked return value of open(2) (CID 1404402, 1404529) * Unchecked return value of dup(2) (CID 1404478) * Buffer overflows. These are all false positives caused by the fact that Coverity thinks I'm using a buffer to store strings, when in fact I'm really just using it to store a byte array that happens to be initialized with a string. I'm changing the type from char to uint8_t in the hopes that it will placate Coverity. (CID 1404338, 1404350, 1404367, 1404376, 1404379, 1404381, 1404388, 1404403, 1404425, 1404433, 1404434, 1404474, 1404480, 1404484, 1404503, 1404505) * False positive file descriptor leak. I'm going to try to fix this with Coverity modeling, but I'll also change an EXPECT to ASSERT so we don't perform meaningless assertions after the failure. (CID 1404320, 1404324, 1404440, 1404445). * Unannotated file descriptor leak. This will be followed up by a Coverity modeling change. (CID 1404326, 1404334, 1404336, 1404357, 1404361, 1404372, 1404391, 1404395, 1404409, 1404430, 1404448, 1404451, 1404455, 1404457, 1404458, 1404460) * Uninitialized variables in C++ constructors (CID 1404327, 1404346). In the case of m_maxphys, this actually led to part of the FUSE_INIT's response being set to stack garbage during the WriteCluster::clustering test. * Uninitialized sun_len field in struct sockaddr_un (CID 1404330, 1404371, 1404429). Reported by: Coverity Reviewed by: emaste MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21457 Notes: svn path=/head/; revision=351963
* fusefs: Fix some bugs regarding the size of the LISTXATTR listAlan Somers2019-08-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * A small error in r338152 let to the returned size always being exactly eight bytes too large. * The FUSE_LISTXATTR operation works like Linux's listxattr(2): if the caller does not provide enough space, then the server should return ERANGE rather than return a truncated list. That's true even though in FUSE's case the kernel doesn't provide space to the client at all; it simply requests a maximum size for the list. We previously weren't handling the case where the server returns ERANGE even though the kernel requested as much size as the server had told us it needs; that can happen due to a race. * We also need to ensure that a pathological server that always returns ERANGE no matter what size we request in FUSE_LISTXATTR won't cause an infinite loop in the kernel. As of this commit, it will instead cause an infinite loop that exits and enters the kernel on each iteration, allowing signals to be processed. Reviewed by: cem MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21287 Notes: svn path=/head/; revision=351560
* fusefs: don't send the namespace during listextattrAlan Somers2019-08-161-6/+3
| | | | | | | | | | | | | | | | | | The FUSE_LISTXATTR operation always returns the full list of a file's extended attributes, in all namespaces. There's no way to filter the list server-side. However, currently FreeBSD's fusefs driver sends a namespace string with the FUSE_LISTXATTR request. That behavior was probably copied from fuse_vnop_getextattr, which has an attribute name argument. It's been there ever since extended attribute support was added in r324620. This commit removes it. Reviewed by: cem MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21280 Notes: svn path=/head/; revision=351113
* fusefs: fix conditional from r351061Alan Somers2019-08-151-2/+1
| | | | | | | | | | | | | | | The entirety of r351061 was a copy/paste error. I'm sorry I've been comitting so hastily. Reported by: rpokala Reviewed by: rpokala MFC after: 2 weeks MFC-With: 351061 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21265 Notes: svn path=/head/; revision=351066
* fusefs: fix the 32-bit build after 351042Alan Somers2019-08-151-1/+2
| | | | | | | | | | Reported by: jhb MFC after: 2 weeks MFC-With: 351042 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=351061
* fusefs: Fix the size of fuse_getattr_inAlan Somers2019-08-141-0/+157
| | | | | | | | | | | | | | | | | | In FUSE protocol 7.9, the size of the FUSE_GETATTR request has increased. However, the fusefs driver is currently not sending the additional fields. In our implementation, the additional fields are always zero, so I there haven't been any test failures until now. But fusefs-lkl requires the request's length to be correct. Fix this bug, and also enhance the test suite to catch similar bugs. PR: 239830 MFC after: 2 weeks MFC-With: 350665 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=351042
* fusefs: add SVN Keywords to the test filesAlan Somers2019-08-131-0/+2
| | | | | | | | | | Reported by: SVN pre-commit hooks MFC after: 15 days MFC-With: r350665 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=350990
* fusefs: fix warnings in the tests reported by GCCAlan Somers2019-07-201-1/+1
| | | | | | | Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350163
* fusefs: add a intr/nointr mount optionAlan Somers2019-07-181-1/+8
| | | | | | | | | | | | | | | | | | | | | | | FUSE file systems can optionally support interrupting outstanding operations. However, the file system does not identify to the kernel at mount time whether it's capable of doing that. Instead it signals its noncapability by returning ENOSYS to the first FUSE_INTERRUPT operation it receives. That's a problem for reliable signal delivery, because the kernel must choose which thread should get a signal before it knows whether the FUSE server can handle interrupts. The problem is even worse because the FUSE protocol allows a file system to simply ignore all FUSE_INTERRUPT operations. Fix the signal delivery logic by making interruptibility an opt-in mount option. This will require a corresponding change to libfuse, but not to most file systems that link to libfuse. Bump __FreeBSD_version due to the new mount option. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350115
* projects/fuse2: build fixesAlan Somers2019-07-131-2/+2
| | | | | | | | | | * Fix the kernel build with gcc by removing a redundant extern declaration * In the tests, fix a printf format specifier that assumed LP64 Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349970
* fusefs: implement the "time_gran" feature.Alan Somers2019-06-261-1/+3
| | | | | | | | | | | | If a server supports a timestamp granularity other than 1ns, it can tell the client this as of protocol 7.23. The client will use that granularity when updating its cached timestamps during write. This way the timestamps won't appear to change following flush. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349403
* fusefs: raise protocol level to 7.23Alan Somers2019-06-211-3/+7
| | | | | | | | | | | None of the new features are implemented yet. This commit just adds the new protocol definitions and adds backwards-compatibility code for pre 7.23 servers. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349263
* fusefs: raise protocol level to 7.15Alan Somers2019-06-201-0/+23
| | | | | | | | | | | | | | | This protocol level adds two new features: the ability for the server to store or retrieve data into/from the client's cache. But the messages aren't defined soundly since they identify the file only by its inode, without the generation number. So it's possible for them to modify the wrong file's cache. Also, I don't know of any file systems in ports that use these messages. So I'm not implementing them. I did add a (disabled) test for the store message, however. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349250
* fusefs: implement VOP_BMAPAlan Somers2019-06-201-0/+4
| | | | | | | | | | | | | | | If the fuse daemon supports FUSE_BMAP, then use that for the block mapping. Otherwise, use the same technique used by vop_stdbmap. Report large values for runp and runb in order to maximize read clustering and minimize upcalls, even if we don't know the true layout. The major result of this change is that sequential reads to FUSE files will now usually happen 128KB at a time instead of 64KB. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349238
* fusefs: use cluster_read for more readaheadAlan Somers2019-06-171-1/+6
| | | | | | | | | | | fusefs will now use cluster_read. This allows readahead of more than one cache block. However, it won't yet actually cluster the reads because that requires VOP_BMAP, which fusefs does not yet implement. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349158
* fusefs: enable write clusteringAlan Somers2019-06-141-10/+7
| | | | | | | | | | | | | | | | Enable write clustering in fusefs whenever cache mode is set to writeback and the "async" mount option is used. With default values for MAXPHYS, DFLTPHYS, and the fuse max_write mount parameter, that means sequential writes will now be written 128KB at a time instead of 64KB. Also, add a regression test for PR 238565, a panic during unmount that probably affects UFS, ext2, and msdosfs as well as fusefs. PR: 238565 Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349036
* fusefs: fix an infinite loop in the testsAlan Somers2019-06-111-2/+4
| | | | | | | | | | It was possible for the MockFS thread to infinitely loop if it got an error reading from /dev/fuse. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=348930
* fusefs: support asynchronous cache invalidationAlan Somers2019-06-031-0/+22
| | | | | | | | | | | | | Protocol 7.12 adds a way for the server to notify the client that it should invalidate an inode's data cache and/or attributes. This commit implements that mechanism. Unlike Linux's implementation, ours requires that the file system also supports FUSE_EXPORT_SUPPORT (NFS-style lookups). Otherwise the invalidation operation will return EINVAL. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=348560
* fusefs: support name cache invalidationAlan Somers2019-06-011-2/+43
| | | | | | | | | | | Protocol 7.12 adds a way for the server to notify the client that it should invalidate an entry from its name cache. This commit implements that mechanism. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=348487
* fusefs: raise protocol level to 7.12Alan Somers2019-05-291-10/+20
| | | | | | | | | | | | | | This commit raises the protocol level and adds backwards-compatibility code to handle structure size changes. It doesn't implement any new features. The new features added in protocol 7.12 are: * server-side umask processing (which FreeBSD won't do) * asynchronous inode and directory entry invalidation (which I'll do next) Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=348365
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-15 02:41:06 +0000