aboutsummaryrefslogtreecommitdiff
path: root/sys/fs/fuse
Commit message (Collapse)AuthorAgeFilesLines
* namei: Fix cn_flags width in various placesMark Johnston2025-11-191-6/+5
| | | | | | | | | | | This truncation is mostly harmless today, but fix it anyway to avoid pain later down the road. Reviewed by: olce, kib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D50417 (cherry picked from commit 0d224af399a66f00a5b33e5512fc018062cabf1d)
* fusefs: fix a memory leakAlan Somers2025-01-201-1/+1
| | | | | | | | | | 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. Sponsored by: ConnectWise (cherry picked from commit 969d1aa4dbfcbccd8de965f7761203208bf04e46)
* fusefs: ignore FUSE_NO_OPEN(DIR)_SUPPORT flagsCismonX2025-01-204-21/+11
| | | | | | | | | | | | | | 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. Reviewed by: Alan Somers <asomers@FreeBSD.org> Signed-off-by: CismonX <admin@cismon.net> Pull Request: https://github.com/freebsd/freebsd-src/pull/1509 (cherry picked from commit f0f596bd955e5b48c55db502e79fc652ac8970d3)
* fusefs: FUSE_NOTIFY_INVAL_* must busy the mountpointAlan Somers2025-01-201-1/+8
| | | | | | | | | | | | | Unusually, the FUSE_NOTIFY_INVAL_INODE and FUSE_NOTIFY_INVAL_ENTRY messages are fully asynchronous. The server sends them to the kernel unsolicited. That means that unlike every other fuse message coming from the server, these two arrive to a potentially unbusied mountpoint. So they must explicitly busy it. Otherwise a page fault could result if the mountpoint were being unmounted. Reported by: JSML4ThWwBID69YC@protonmail.com (cherry picked from commit 989998529387b4d98dfaa6c499ad88b006f78de8)
* fusefs: fix two bugs regarding _PC_MIN_HOLE_SIZEAlan Somers2024-07-081-10/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Sponsored by: Axcient Differential Revision: https://reviews.freebsd.org/D44618 (cherry picked from commit 6efba04df3f8c77b9b12f1df3e5124a7249b82fc)
* fusefs: correct a commentAlan Somers2024-06-131-4/+5
| | | | | | | | [skip ci] Sponsored by: Axcient (cherry picked from commit c1326c01df81dd06739ddf1946e1968ddaba0c8e)
* fusefs: only test for incoherency if FN_SIZECHANGE is setEmil Tsalapatis2024-06-131-2/+2
| | | | | | | | | | | | | | | FUSE emits spurious incoherency warnings in writethrough mode. The warnings are triggered by setattr calls generated by vnode truncation turning the cached va_size vattr stale, causing comparisons with the fresh version provided by the server to fail. Only validate the vnode's va_size vattr if the FN_SIZECHANGE flag is set. This is a part of the research work at RCSLab, University of Waterloo. Reviewed by: asomers Pull Request: https://github.com/freebsd/freebsd-src/pull/1110 (cherry picked from commit 8758bf0aaec1d4b2ebcb429e8cabc691c2c95461)
* fusefs: fix invalid value for st_birthtime.tv_nsecAlan Somers2024-02-122-1/+7
| | | | | | | | | | | | | | | | | | | | | | | 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 Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D43590
* fusefs: fix an interaction between copy_file_range and mmapAlan Somers2024-02-021-0/+1
| | | | | | | | | | If a copy_file_range operation tries to read from a page that was previously written via mmap, that page must be flushed first. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D43451 (cherry picked from commit 1c909c300b92601f7690610097ac98126caff835)
* fusefs(5): Fix a typo in a SDT probeGordon Bergling2024-01-251-1/+1
| | | | | | - s/userpace/userspace/ (cherry picked from commit 6f0da017c973f40c1bc70552c922c500a0a8c858)
* Add vnode_pager_clean_{a,}sync(9)Konstantin Belousov2024-01-181-5/+2
| | | | (cherry picked from commit b068bb09a1a82d9fef0e939ad6135443a959e290)
* vn_copy_file_range(): provide ENOSYS fallback to vn_generic_copy_file_range()Konstantin Belousov2023-12-051-5/+2
| | | | (cherry picked from commit c5405d1c850765d04f74067ebb71f57e9a26b8ea)
* fuse_vnop_copy_file_range(): add safetyKonstantin Belousov2023-11-231-1/+2
| | | | (cherry picked from commit 4c6cded2166111079c6b5e8b2353171dcc7ed0c4)
* fuse_vnop_copy_file_range(): use vn_lock_pair()Konstantin Belousov2023-11-231-17/+5
| | | | (cherry picked from commit 318c56714aa8c170132ebe008f52904e0f119b5f)
* fusefs: sanitize FUSE_READLINK results for embedded NULsAlan Somers2023-10-152-0/+8
| | | | | | | | | | | | | If VOP_READLINK returns a path that contains a NUL, it will trigger an assertion in vfs_lookup. Sanitize such paths in fusefs, rejecting any and warning the user about the misbehaving server. PR: 274268 Sponsored by: Axcient Reviewed by: mjg, markj Differential Revision: https://reviews.freebsd.org/D42081 (cherry picked from commit 662ec2f781521c36b76af748d74bb0a3c2e27a76)
* fusefs: fix some bugs updating atime during closeAlan Somers2023-10-051-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | When using cached attributes, we must update a file's atime during close, if it has been read since the last attribute refresh. But, * Don't update atime if we lack write permissions to the file or if the file system is readonly. * If the daemon fails our atime update request for any reason, don't report this as a failure for VOP_CLOSE. PR: 270749 Reported by: Jamie Landeg-Jones <jamie@catflap.org> Sponsored by: Axcient Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D41925 (cherry picked from commit fb619c94c679e939496fe0cf94b8d2cba95e6e63) fusefs: fix unused variables from fb619c94c67 PR: 270749 Reported by: cy Sponsored by: Axcient (cherry picked from commit e5236d25f2c0709acf3547e6af45f4bb4eec4f02)
* sys: Remove $FreeBSD$: one-line .c patternWarner Losh2023-08-239-18/+0
| | | | | | | Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ Similar commit in current: (cherry picked from commit 685dc743dc3b)
* sys: Remove $FreeBSD$: two-line .h patternWarner Losh2023-08-237-14/+0
| | | | | | | Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/ Similar commit in current: (cherry picked from commit 95ee2897e98f)
* fusefs: Remove an unused pbuf zoneMark Johnston2023-05-292-5/+0
| | | | | | | | | | | | | The zone has been dead ever since commit b9e20197551d ("fusefs: rewrite vop_getpages and vop_putpages") No functional change intended. Reviewed by: asomers MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D40143 (cherry picked from commit e3f7081b1c54fae55cb443a39c2ad44ac3ed4a75)
* fusefs: fix some resource leaksAlan Somers2023-02-191-0/+2
| | | | | | | | | | | | | | | fusefs would leak tickets in three cases: * After FUSE_CREATE, if the server returned a bad inode number. * After a FUSE_FALLOCATE operation during VOP_ALLOCATE * After a FUSE_FALLOCATE operation during VOP_DEALLOCATE Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D38526 (cherry picked from commit 1bdf879b97b686a8f36fdba050b68f9e7493f363) MFC Note: changes to VOP_DEALLOCATE are not MFCed, because that VOP does not exist in stable/13.
* fusefs: fix VOP_ADVLOCK with SEEK_ENDAlan Somers2022-11-231-2/+31
| | | | | | | | | | | | When the user specifies SEEK_END, unlike SEEK_CUR, VOP_ADVLOCK must adjust lock offsets itself. Sort-of related to bug 266886. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D37040 (cherry picked from commit f6e5319550f60170840f1a07a9cbdd45b5014a21)
* fusefs: After successful F_GETLK, l_whence should be SEEK_SETAlan Somers2022-10-311-0/+1
| | | | | | | | | PR: 266886 Reported by: John Millikin <jmillikin@gmail.com> Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D37014 (cherry picked from commit 3c3b906b54236841d813fd9a01b1e090f39558ea)
* fusefs: during F_GETLK, don't change l_pid if no lock is foundAlan Somers2022-10-311-1/+1
| | | | | | | | | | PR: 266885 Submitted by: John Millikin <jmillikin@gmail.com> Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D36905 (cherry picked from commit 46fcf947c6c8db1e1ceb3cbd75b69d1d1e494929)
* copy_file_range: truncate write if it would exceed RLIMIT_FSIZEAlan Somers2022-10-121-5/+10
| | | | | | | | PR: 266611 Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D36706 (cherry picked from commit 52360ca32ff90b605ac7481fd79e6a251e8b5116)
* fusefs: truncate write if it would exceed RLIMIT_FSIZEAlan Somers2022-10-121-4/+12
| | | | | | | | PR: 164793 Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D36703 (cherry picked from commit be280f60dd8e8ef765a76966aac9c6ca7d6264d0)
* fusefs: respect RLIMIT_FSIZE during truncateAlan Somers2022-10-121-0/+3
| | | | | | | | PR: 164793 Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D36703 (cherry picked from commit 0a192b3abab19deac70f762cd1ec45ba09ec47ca)
* filesystems: return error from vn_rlimit_fsize() instead of EFBIGKonstantin Belousov2022-10-081-4/+6
| | | | (cherry picked from commit cc65a412ae226136e6207bdc8db4722dab99982f)
* fusefs: handle evil servers that return illegal inode numbersAlan Somers2022-06-183-3/+31
| | | | | | | | | | | | | | | | | | | | | * If during FUSE_CREATE, FUSE_MKDIR, etc the server returns the same inode number for the new file as for its parent directory, reject it. Previously this would triggers a recurse-on-non-recursive lock panic. * If during FUSE_LINK the server returns a different inode number for the new name as for the old one, reject it. Obviously, that can't be a hard link. * If during FUSE_LOOKUP the server returns the same inode number for the new file as for its parent directory, reject it. Nothing good can come of this. PR: 263662 Reported by: Robert Morris <rtm@lcs.mit.edu> Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D35128 (cherry picked from commit 0bef4927ea858bb18b6f679bc0a36cff264dc842)
* fusefs: fix an undefined variable accessAlan Somers2022-05-231-1/+1
| | | | | | | | | In an error path, a dtrace probe could access an undefined variable. Reported by: Coverity (CID 1471986) Sponsored by: Axcient (cherry picked from commit dcfa054216ef8dfebed9c7c06c066bce0098bd94)
* fusefs: use the fsname mount option if setAlan Somers2022-05-231-2/+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> Differential Revision: https://reviews.freebsd.org/D35090 (cherry picked from commit 2f6362484c0e1250ef6a76cccdbe4a95587e850c)
* fusefs: fix FUSE_CREATE with file handles and fuse protocol < 7.9Alan Somers2022-05-121-1/+5
| | | | | | | | | | | | | Prior to fuse protocol version 7.9, the fuse_entry_out structure had a smaller size. But fuse_vnop_create did not take that into account when working with servers that use older protocols. The bug does not matter for servers which don't use file handles or open flags (the only fields affected). PR: 263625 Submitted by: Ali Abdallah <ali.abdallah@suse.com> (cherry picked from commit 45825a12f9851213e627cf41398706bacb793f83)
* fusefs: correctly handle servers that report too much data writtenAlan Somers2022-05-121-6/+12
| | | | | | | | | | | | | | | | | | | | | | During a FUSE_WRITE, the kernel requests the server to write a certain amount of data, and the server responds with the amount that it actually did write. It is obviously an error for the server to write more than it was provided, and we always treated it as such, but there were two problems: * If the server responded with a huge amount, greater than INT_MAX, it would trigger an integer overflow which would cause a panic. * When extending the file, we wrongly set the file's size before validing the amount written. PR: 263263 Reported by: Robert Morris <rtm@lcs.mit.edu> Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D34955 (cherry picked from commit 3a1b3c6a1e68063330e897a5a5c94518edae4a3b)
* fusefs: validate servers' error valuesAlan Somers2022-05-121-2/+12
| | | | | | | | | | | | | | | | | | 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> Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D34931 (cherry picked from commit 155ac516c60f20573d15c54bafabfd0e52d21fa6)
* fusefs: fix two bugs regarding VOP_RECLAIM of the root inodeAlan Somers2022-04-291-1/+18
| | | | | | | | | | | | | | | | | * We never send FUSE_LOOKUP for the root inode, since its inode number is hard-coded to 1. Therefore, we should not send FUSE_FORGET for it, lest the server see its lookup count fall below 0. * During VOP_RECLAIM, if we are reclaiming the root inode, we must clear the file system's vroot pointer. Otherwise it will be left pointing at a reclaimed vnode, which will cause future VOP_LOOKUP operations to fail. Previously we only cleared that pointer during VFS_UMOUNT. I don't know of any real-world way to trigger this bug. Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D34753 (cherry picked from commit 32273253667b941c376cf08383006b3a0cbc5ca2)
* fusefs(5): Fix a typo in a source code commentGordon Bergling2022-04-091-1/+1
| | | | | | - s/accomodate/accommodate/ (cherry picked from commit ef1534cad8a085946105e135d2d75e275011ec4b)
* fusefs: Initialize a pad word in the mknod messageMark Johnston2022-03-211-0/+1
| | | | | | | | Reported by: Jenkins (KMSAN job) Reviewed by: asomers Sponsored by: The FreeBSD Foundation (cherry picked from commit c0b98fe16f253d6b5693adeb38cdb78cadb5f58d)
* fusefs: fix a cached attributes bug during directory renameAlan Somers2022-03-091-1/+1
| | | | | | | | | | | When renaming a directory into a different parent directory, invalidate the cached attributes of the new parent. Otherwise, stat will show the wrong st_nlink value. Reviewed by: ngie Differential Revision: https://reviews.freebsd.org/D34336 (cherry picked from commit e8553be9bcfc2c0d78e9f379bd166dc0a9cae719)
* fuse: Fix build on 32-bit architecturesJessica Clarke2022-03-031-1/+1
| | | | | | | | | | MFC 3d721de049be ("Fix NFS exports of FUSE file systems for big directories") missed a case of a uint64_t from HEAD that should be a u_long in 13 due to KPI differences. Specifically, HEAD has b214fcceacad ("Change VOP_READDIR's cookies argument to a **uint64_t"), but stable/13 does not. This is a direct commit to stable/13.
* Fix NFS exports of FUSE file systems for big directoriesAlan Somers2022-03-023-74/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FUSE protocol does not require that a directory entry's d_off field outlive the lifetime of its directory's file handle. Since the NFS server must reopen the directory on every VOP_READDIR call, that means it can't pass uio->uio_offset down to the FUSE server. Instead, it must read the directory from 0 each time. It may need to issue multiple FUSE_READDIR operations until it finds the d_off field that it's looking for. That was the intention behind SVN r348209 and r297887, but a logic bug prevented subsequent FUSE_READDIR operations from ever being issued, rendering large directories incompletely browseable. Reviewed by: rmacklem (cherry picked from commit d088dc76e1a62ecb6c05bd2b14ee48a9f9a7e2bd) fusefs: optimize NFS readdir for FUSE_NO_OPENDIR_SUPPORT In its lowest common denominator, FUSE does not require that a directory entry's d_off field is valid outside of the lifetime of the directory's FUSE file handle. But since NFS is stateless, it must reopen the directory on every call to VOP_READDIR. That means reading the directory all the way from the first entry. Not only does this create an O(n^2) condition for large directories, but it can also result in incorrect behavior if either: * The file system _does_ change the d_off field for the last directory entry previously seen by NFS, or * The file system deletes the last directory entry previously seen by NFS. Handily, for file systems that set FUSE_NO_OPENDIR_SUPPORT d_off is guaranteed to be valid for the lifetime of the directory entry, there is no need to read the directory from the start. Reviewed by: rmacklem (cherry picked from commit 4a6526d84a56f398732bff491e63aa42f796a27d) fusefs: require FUSE_NO_OPENDIR_SUPPORT for NFS exporting FUSE file systems that do not set FUSE_NO_OPENDIR_SUPPORT do not guarantee that d_off will be valid after closing and reopening a directory. That conflicts with NFS's statelessness, that results in unresolvable bugs when NFS reads large directories, if: * The file system _does_ change the d_off field for the last directory entry previously returned by VOP_READDIR, or * The file system deletes the last directory entry previously seen by NFS. Rather than doing a poor job of exporting such file systems, it's better just to refuse. Even though this is technically a breaking change, 13.0-RELEASE's NFS-FUSE support was bad enough that an MFC should be allowed. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D33726 (cherry picked from commit 00134a07898fa807b8a1fcb2596f0e3644143f69) fusefs: fix the build without INVARIANTS after 00134a07898 MFC with: 00134a07898fa807b8a1fcb2596f0e3644143f69 Reported by: se (cherry picked from commit 18ed2ce77a254f365a4687d6afe8eeba2aad2e13)
* fusefs: Address -Wunused-but-set-variable warningsMark Johnston2022-01-274-23/+1
| | | | | | Reviewed by: asomers (cherry picked from commit 3d8562348c9cf1a6bdc32382f5f45a0534da094a)
* fusefs: implement VOP_ALLOCATEAlan Somers2022-01-183-1/+100
| | | | | | | | | | Now posix_fallocate will be correctly forwarded to fuse file system servers, for those that support it. Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33389 (cherry picked from commit 398c88c7582a195cbfeb689ceff1400cc717673f)
* fusefs: in the tests, always assume debug.try_reclaim_vnode is availableAlan Somers2022-01-181-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In an earlier version of the revision that created that sysctl (D20519) the sysctl was gated by INVARIANTS, so the test had to check for it. But in the committed version it is always available. (cherry picked from commit 19ab361045343bb777176bb08468f7706d7649c4) fusefs: move common code from forget.cc to utils.cc (cherry picked from commit 8d99a6b91b788b7ddf88f975f288f7c6479f4be3) fusefs: fix .. lookups when the parent has been reclaimed. By default, FUSE file systems are assumed not to support lookups for "." and "..". They must opt-in to that. To cope with this limitation, the fusefs kernel module caches every fuse vnode's parent's inode number, and uses that during VOP_LOOKUP for "..". But if the parent's vnode has been reclaimed that won't be possible. Previously we paniced in this situation. Now, we'll return ESTALE instead. Or, if the file system has opted into ".." lookups, we'll just do that instead. This commit also fixes VOP_LOOKUP to respect the cache timeout for ".." lookups, if the FUSE file system specified a finite timeout. PR: 259974 Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33239 (cherry picked from commit 1613087a8127122b03a3730046d051adf4edd14f)
* fusefs: copy_file_range must update file timestampsAlan Somers2022-01-181-0/+2
| | | | | | | | | | If FUSE_COPY_FILE_RANGE returns successfully, update the atime of the source and the mtime and ctime of the destination. Reviewers: pfg Differential Revision: https://reviews.freebsd.org/D33159 (cherry picked from commit 5169832c96451e0c939338d8ef34cd0875a24b83)
* Fix a race in fusefs that can corrupt a file's size.Alan Somers2022-01-186-9/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | VOPs like VOP_SETATTR can change a file's size, with the vnode exclusively locked. But VOPs like VOP_LOOKUP look up the file size from the server without the vnode locked. So a race is possible. For example: 1) One thread calls VOP_SETATTR to truncate a file. It locks the vnode and sends FUSE_SETATTR to the server. 2) A second thread calls VOP_LOOKUP and fetches the file's attributes from the server. Then it blocks trying to acquire the vnode lock. 3) FUSE_SETATTR returns and the first thread releases the vnode lock. 4) The second thread acquires the vnode lock and caches the file's attributes, which are now out-of-date. Fix this race by recording a timestamp in the vnode of the last time that its filesize was modified. Check that timestamp during VOP_LOOKUP and VFS_VGET. If it's newer than the time at which FUSE_LOOKUP was issued to the server, ignore the attributes returned by FUSE_LOOKUP. PR: 259071 Reported by: Agata <chogata@moosefs.pro> Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33158 (cherry picked from commit 13d593a5b060cf7be40acfa2ca9dc9e0e2339a31)
* fusefs: invalidate the cache during copy_file_rangeAlan Somers2022-01-031-0/+10
| | | | | | | | | | | FUSE_COPY_FILE_RANGE instructs the server to write data to a file. fusefs must invalidate any cached data within the written range. PR: 260242 Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33280 (cherry picked from commit 41ae9f9e644d1196bebacdb3748670f36b354384)
* fusefs: inline fuse_io_dispatchAlan Somers2022-01-033-181/+178
| | | | | | | | This function was always confusing, because it created an H-shaped callgraph: two functions called in and left via different paths based on which which called. (cherry picked from commit dc433e1530af26b0430d66c06c342889e9609590)
* fusefs: correctly handle an inode that changes file typesAlan Somers2022-01-032-14/+20
| | | | | | | | | | | | | | | | | | | | | | | | Correctly handle the situation where a FUSE server unlinks a file, then creates a new file of a different type but with the same inode number. Previously fuse_vnop_lookup in this situation would return EAGAIN. But since it didn't call vgone(), the vnode couldn't be reused right away. Fix this by immediately calling vgone() and reallocating a new vnode. This problem can occur in three code paths, during VOP_LOOKUP, VOP_SETATTR, or following FUSE_GETATTR, which usually happens during VOP_GETATTR but can occur during other vops, too. Note that the correct response actually doesn't depend on whether the entry cache has expired. In fact, during VOP_LOOKUP, we can't even tell. Either it has expired already, or else the vnode got reclaimed by vnlru. Also, correct the error code during the VOP_SETATTR path. PR: 258022 Reported by: chogata@moosefs.pro Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33283 (cherry picked from commit 25927e068fcbcac0a5111a881de723bd984b04b3)
* modules: increase MAXMODNAME and provide backward compatBjoern A. Zeeb2021-12-303-0/+3
| | | | | | | | | | | | | | | | | | | | | | | With various firmware files used by graphics and wireless drivers we are exceeding the current 32 character module name (file path in kldxref) length. In order to overcome this issue bump it to the maximum path length for the next version. To be able to MFC provide backward compat support for another version of the struct as the offsets for the second half change due to the array size increase. MAXMODNAME being defined to MAXPATHLEN needs param.h to be included first. With only 7 modules (or LinuxKPI module.h) not doing that adjust them rather than including param.h in module.h [1]. Reported by: Greg V (greg unrelenting.technology) Sponsored by: The FreeBSD Foundation Suggested by: imp [1] Reviewed by: imp (and others to different level) Differential Revision: https://reviews.freebsd.org/D32383 (cherry picked from commit df38ada2931f95d07b65b19fcfb4c9845d656ba9)
* fusefs: update atime on reads when using cached attributesAlan Somers2021-12-145-6/+33
| | | | | | | | | | | | | | | | | | | | 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. Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33145 (cherry picked from commit 91972cfcddf950d7a9c33df5a9171ada1805a144) fusefs: fix 32-bit build of the tests after 91972cfcddf (cherry picked from commit d109559ddbf7afe311c1f1795ece137071406db8)
* fusefs: fix copy_file_range when extending a fileAlan Somers2021-12-141-0/+3
| | | | | | | | | | When copy_file_range extends a file, it must update the cached file size. Reviewed by: rmacklem, pfg Differential Revision: https://reviews.freebsd.org/D33151 (cherry picked from commit 65d70b3bae0c70798b0a2b8ed129bc146fed1cce)
generated by cgit v1.3 (git 2.53.0) at 2026-08-03 21:57:25 +0000