aboutsummaryrefslogtreecommitdiff
path: root/sys/fs/fuse
Commit message (Collapse)AuthorAgeFilesLines
* Make MAXPHYS tunable. Bump MAXPHYS to 1M.Konstantin Belousov2020-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace MAXPHYS by runtime variable maxphys. It is initialized from MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys. Make b_pages[] array in struct buf flexible. Size b_pages[] for buffer cache buffers exactly to atop(maxbcachebuf) (currently it is sized to atop(MAXPHYS)), and b_pages[] for pbufs is sized to atop(maxphys) + 1. The +1 for pbufs allow several pbuf consumers, among them vmapbuf(), to use unaligned buffers still sized to maxphys, esp. when such buffers come from userspace (*). Overall, we save significant amount of otherwise wasted memory in b_pages[] for buffer cache buffers, while bumping MAXPHYS to desired high value. Eliminate all direct uses of the MAXPHYS constant in kernel and driver sources, except a place which initialize maxphys. Some random (and arguably weird) uses of MAXPHYS, e.g. in linuxolator, are converted straight. Some drivers, which use MAXPHYS to size embeded structures, get private MAXPHYS-like constant; their convertion is out of scope for this work. Changes to cam/, dev/ahci, dev/ata, dev/mpr, dev/mpt, dev/mvs, dev/siis, where either submitted by, or based on changes by mav. Suggested by: mav (*) Reviewed by: imp, mav, imp, mckusick, scottl (intermediate versions) Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D27225 Notes: svn path=/head/; revision=368124
* Split out cwd/root/jail, cmask state from filedesc tableConrad Meyer2020-11-172-3/+3
| | | | | | | | | | | | | | | | No functional change intended. Tracking these structures separately for each proc enables future work to correctly emulate clone(2) in linux(4). __FreeBSD_version is bumped (to 1300130) for consumption by, e.g., lsof. Reviewed by: kib Discussed with: markj, mjg Differential Revision: https://reviews.freebsd.org/D27037 Notes: svn path=/head/; revision=367777
* Make it possible to mount a fuse filesystem, such as squashfuse,Edward Tomasz Napierala2020-11-093-0/+17
| | | | | | | | | | | | from a Linux binary. Should come handy for AppImages. Reviewed by: asomers MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26959 Notes: svn path=/head/; revision=367517
* vfs: drop the de facto curthread argument from VOP_INACTIVEMateusz Guzik2020-10-201-2/+1
| | | | Notes: svn path=/head/; revision=366870
* fusefs: fix mmap'd writes in direct_io modeAlan Somers2020-09-241-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | If a FUSE server returns FOPEN_DIRECT_IO in response to FUSE_OPEN, that instructs the kernel to bypass the page cache for that file. This feature is also known by libfuse's name: "direct_io". However, when accessing a file via mmap, there is no possible way to bypass the cache completely. This change fixes a deadlock that would happen when an mmap'd write tried to invalidate a portion of the cache, wrongly assuming that a write couldn't possibly come from cache if direct_io were set. Arguably, we could instead disable mmap for files with FOPEN_DIRECT_IO set. But allowing it is less likely to cause user complaints, and is more in keeping with the spirit of open(2), where O_DIRECT instructs the kernel to "reduce", not "eliminate" cache effects. PR: 247276 Reported by: trapexit@spawn.link Reviewed by: cem MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D26485 Notes: svn path=/head/; revision=366121
* fs: clean up empty lines in .c and .h filesMateusz Guzik2020-09-017-13/+5
| | | | Notes: svn path=/head/; revision=365070
* fuse: unbreak after r364814Mateusz Guzik2020-08-261-1/+2
| | | | | | | Reported by: kevans Notes: svn path=/head/; revision=364837
* vfs: remove the always-curthread td argument from VOP_RECLAIMMateusz Guzik2020-08-191-2/+1
| | | | Notes: svn path=/head/; revision=364373
* vfs: remove the thread argument from vgetMateusz Guzik2020-08-161-1/+1
| | | | | | | | | | | | | | | | | | It was already asserted to be curthread. Semantic patch: @@ expression arg1, arg2, arg3; @@ - vget(arg1, arg2, arg3) + vget(arg1, arg2) Notes: svn path=/head/; revision=364271
* vfs: remove the obsolete privused argument from vaccessMateusz Guzik2020-08-051-1/+1
| | | | | | | | This brings argument count down to 6, which is passable without the stack on amd64. Notes: svn path=/head/; revision=363893
* copystr(9): Move to deprecate (attempt #2)Conrad Meyer2020-05-251-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies logical r360944 and r360946 (reverting r360955), with fixed copystr() stand-in replacement macro. Eventually the goal is to convert consumers and kill the macro, but for a first step it helps if the macro is correct. Prior commit message: Unlike the other copy*() functions, it does not serve to copy from one address space to another or protect against potential faults. It's just an older incarnation of the now-more-common strlcpy(). Add a coccinelle script to tools/ which can be used to mechanically convert existing instances where replacement with strlcpy is trivial. In the two cases which matched, fuse_vfsops.c and union_vfsops.c, the code was further refactored manually to simplify. Replace the declaration of copystr() in systm.h with a small macro wrapper around strlcpy (with correction from brooks@ -- thanks). Remove N redundant MI implementations of copystr. For MIPS, this entailed inlining the assembler copystr into the only consumer, copyinstr, and making the latter a leaf function. Reviewed by: jhb (earlier version) Discussed with: brooks (thanks!) Differential Revision: https://reviews.freebsd.org/D24672 Notes: svn path=/head/; revision=361466
* Fix issues with FUSE_ACCESS when default_permissions is disabledAlan Somers2020-05-222-7/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes two issues relating to FUSE_ACCESS when the default_permissions mount option is disabled: * VOP_ACCESS() calls with VADMIN set should never be sent to a fuse server in the form of FUSE_ACCESS operations. The FUSE protocol has no equivalent of VADMIN, so we must evaluate such things kernel-side, regardless of the default_permissions setting. * The FUSE protocol only requires FUSE_ACCESS to be sent for two purposes: for the access(2) syscall and to check directory permissions for searchability during lookup. FreeBSD sends it much more frequently, due to differences between our VFS and Linux's, for which FUSE was designed. But this patch does eliminate several cases not required by the FUSE protocol: * for any FUSE_*XATTR operation * when creating a new file * when deleting a file * when setting timestamps, such as by utimensat(2). * Additionally, when default_permissions is disabled, this patch removes one FUSE_GETATTR operation when deleting a file. PR: 245689 Reported by: MooseFS FreeBSD Team <freebsd@moosefs.pro> Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24777 Notes: svn path=/head/; revision=361401
* Disable nullfs cacheing on top of fusefsAlan Somers2020-05-221-0/+5
| | | | | | | | | | | | | | Nullfs cacheing can keep a large number of vnodes active. That results in more active FUSE file handles, causing some FUSE servers to use extra resources. Disable nullfs cacheing for fusefs, just like we already do for NFSv4. PR: 245688 Reported by: MooseFS FreeBSD Team <freebsd@moosefs.pro> MFC after: 2 weeks Notes: svn path=/head/; revision=361399
* Revert r360944 and r360946 until reported issues can be resolvedConrad Meyer2020-05-121-2/+4
| | | | | | | Reported by: cy Notes: svn path=/head/; revision=360955
* copystr(9): Move to deprecate [2/2]Conrad Meyer2020-05-111-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | Unlike the other copy*() functions, it does not serve to copy from one address space to another or protect against potential faults. It's just an older incarnation of the now-more-common strlcpy(). Add a coccinelle script to tools/ which can be used to mechanically convert existing instances where replacement with strlcpy is trivial. In the two cases which matched, fuse_vfsops.c and union_vfsops.c, the code was further refactored manually to simplify. Replace the declaration of copystr() in systm.h with a small macro wrapper around strlcpy. Remove N redundant MI implementations of copystr. For MIPS, this entailed inlining the assembler copystr into the only consumer, copyinstr, and making the latter a leaf function. Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D24672 Notes: svn path=/head/; revision=360944
* fusefs: better dtrace probes for asynchronous invalidation operationsAlan Somers2020-05-081-2/+6
| | | | | | | MFC after: 2 weeks Notes: svn path=/head/; revision=360828
* fusefs: add a dtrace probe that fires after mounting is completeAlan Somers2020-03-301-0/+3
| | | | | | | | | | This probe is useful for showing the protocol options negotiated with a FUSE server. MFC after: 2 weeks Notes: svn path=/head/; revision=359435
* fusefs: avoid cache corruption with buggy fuse serversAlan Somers2020-03-114-17/+53
| | | | | | | | | | | | | | | | | | | The FUSE protocol allows the client (kernel) to cache a file's size, if the server (userspace daemon) allows it. A well-behaved daemon obviously should not change a file's size while a client has it cached. But a buggy daemon might. If the kernel ever detects that that has happened, then it should invalidate the entire cache for that file. Previously, we would not only cache stale data, but in the case of a file extension while we had the size cached, we accidentally extended the cache with zeros. PR: 244178 Reported by: Ben RUBSON <ben.rubson@gmx.com> Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24012 Notes: svn path=/head/; revision=358867
* fusefs: fix fsync for files with multiple open handlesAlan Somers2020-03-091-0/+1
| | | | | | | | | | | | | | We were reusing a structure for multiple operations, but failing to reinitialize one member. The result is that a server that cares about FUSE file handle IDs would see one correct FUSE_FSYNC operation, and one with the FHID unset. PR: 244431 Reported by: Agata <chogata@gmail.com> MFC after: 2 weeks Notes: svn path=/head/; revision=358798
* Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (8 of many)Pawel Biernacki2020-02-241-2/+4
| | | | | | | | | | | | | | | r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Approved by: kib (mentor, blanket) Differential Revision: https://reviews.freebsd.org/D23627 Notes: svn path=/head/; revision=358275
* Provide O_SEARCHKyle Evans2020-02-021-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | O_SEARCH is defined by POSIX [0] to open a directory for searching, skipping permissions checks on the directory itself after the initial open(). This is close to the semantics we've historically applied for O_EXEC on a directory, which is UB according to POSIX. Conveniently, O_SEARCH on a file is also explicitly undefined behavior according to POSIX, so O_EXEC would be a fine choice. The spec goes on to state that O_SEARCH and O_EXEC need not be distinct values, but they're not defined to be the same value. This was pointed out as an incompatibility with other systems that had made its way into libarchive, which had assumed that O_EXEC was an alias for O_SEARCH. This defines compatibility O_SEARCH/FSEARCH (equivalent to O_EXEC and FEXEC respectively) and expands our UB for O_EXEC on a directory. O_EXEC on a directory is checked in vn_open_vnode already, so for completeness we add a NOEXECCHECK when O_SEARCH has been specified on the top-level fd and do not re-check that when descending in namei. [0] https://pubs.opengroup.org/onlinepubs/9699919799/ Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D23247 Notes: svn path=/head/; revision=357412
* fusefs: add missing CLTFLAG_MPSAFE annotationMateusz Guzik2020-01-151-1/+2
| | | | Notes: svn path=/head/; revision=356742
* vfs: drop the mostly unused flags argument from VOP_UNLOCKMateusz Guzik2020-01-031-1/+1
| | | | | | | | | | | Filesystems which want to use it in limited capacity can employ the VOP_UNLOCK_FLAGS macro. Reviewed by: kib (previous version) Differential Revision: https://reviews.freebsd.org/D21427 Notes: svn path=/head/; revision=356337
* vfs: flatten vop vectorsMateusz Guzik2019-12-161-0/+2
| | | | | | | | | | | | | | | This eliminates the following loop from all VOP calls: while(vop != NULL && \ vop->vop_spare2 == NULL && vop->vop_bypass == NULL) vop = vop->vop_default; Reviewed by: jeff Tesetd by: pho Differential Revision: https://reviews.freebsd.org/D22738 Notes: svn path=/head/; revision=355790
* vfs: introduce v_irflag and make v_type smallerMateusz Guzik2019-12-081-1/+1
| | | | | | | | | | | | | | | | | | The current vnode layout is not smp-friendly by having frequently read data avoidably sharing cachelines with very frequently modified fields. In particular v_iflag inspected for VI_DOOMED can be found in the same line with v_usecount. Instead make it available in the same cacheline as the v_op, v_data and v_type which all get read all the time. v_type is avoidably 4 bytes while the necessary data will easily fit in 1. Shrinking it frees up 3 bytes, 2 of which get used here to introduce a new flag field with a new value: VIRF_DOOMED. Reviewed by: kib, jeff Differential Revision: https://reviews.freebsd.org/D22715 Notes: svn path=/head/; revision=355537
* Fix an off-by-one error from r351961Alan Somers2019-09-161-1/+1
| | | | | | | | | | | | | | That revision addressed a Coverity CID that could lead to a buffer overflow, but it had an off-by-one error in the buffer size check. Reported by: Coverity Coverity CID: 1405530 MFC after: 3 days MFC-With: 351961 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=352417
* fusefs: fix some minor issues with fuse_vnode_setparentAlan Somers2019-09-162-2/+3
| | | | | | | | | | | | | | | | | * When unparenting a vnode, actually clear the flag. AFAIK this is basically a no-op because we only unparent a vnode when reclaiming it or when unlinking. * There's no need to call fuse_vnode_setparent during reclaim, because we're about to free the vnode data anyway. Reviewed by: emaste MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21630 Notes: svn path=/head/; revision=352404
* fusefs: Fix iosize for FUSE_WRITE in 7.8 compat modeAlan Somers2019-09-111-6/+11
| | | | | | | | | | | | | | | | | 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
* Coverity fixes in fusefs(5)Alan Somers2019-09-062-1/+4
| | | | | | | | | | | | | | | | | | | CID 1404532 fixes a signed vs unsigned comparison error in fuse_vnop_bmap. It could potentially have resulted in VOP_BMAP reporting too many consecutive blocks. CID 1404364 is much worse. It was an array access by an untrusted, user-provided variable. It could potentially have resulted in a malicious file system crashing the kernel or worse. Reported by: Coverity Reviewed by: emaste MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21466 Notes: svn path=/head/; revision=351961
* Remove unused VM page locking macros.Mark Johnston2019-08-291-5/+0
| | | | | | | | | | | | They were orphaned by r292373. Reviewed by: asomers MFC after: 1 week Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D21469 Notes: svn path=/head/; revision=351613
* Rework v_object lifecycle for vnodes.Konstantin Belousov2019-08-291-1/+0
| | | | | | | | | | | | | | | | | | | | | | | Current implementation of vnode_create_vobject() and vnode_destroy_vobject() is written so that it prepared to handle the vm object destruction for live vnode. Practically, no filesystems use this, except for some remnants that were present in UFS till today. One of the consequences of that model is that each filesystem must call vnode_destroy_vobject() in VOP_RECLAIM() or earlier, as result all of them get rid of the v_object in reclaim. Move the call to vnode_destroy_vobject() to vgonel() before VOP_RECLAIM(). This makes v_object stable: either the object is NULL, or it is valid vm object till the vnode reclamation. Remove code from vnode_create_vobject() to handle races with the parallel destruction. Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D21412 Notes: svn path=/head/; revision=351598
* fusefs: Fix some bugs regarding the size of the LISTXATTR listAlan Somers2019-08-281-3/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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-9/+1
| | | | | | | | | | | | | | | | | | 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 the size of fuse_getattr_inAlan Somers2019-08-141-2/+2
| | | | | | | | | | | | | | | | | | 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: remove superfluous counter_u64_zeroAlan Somers2019-08-064-5/+0
| | | | | | | | Reported by: glebius Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350621
* fusefs: fix the build after r350446Alan Somers2019-07-311-0/+1
| | | | | | | | | fuse needs to include an additional header after r350446 Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350489
* MFHead @350426Alan Somers2019-07-301-0/+1
|\ | | | | | | | | | | | | Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350435
| * Avoid relying on header pollution from sys/refcount.h.Mark Johnston2019-07-291-0/+1
| | | | | | | | | | | | | | | | MFC after: 3 days Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=350421
* | fusefs: fix panic when writing with O_DIRECT and using writeback cacheAlan Somers2019-07-281-3/+58
| | | | | | | | | | | | | | | | | | | | | | | | When a fusefs file system is mounted using the writeback cache, the cache may still be bypassed by opening a file with O_DIRECT. When writing with O_DIRECT, the cache must be invalidated for the affected portion of the file. Fix some panics caused by inadvertently invalidating too much. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350388
* | fusefs: add a intr/nointr mount optionAlan Somers2019-07-183-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | fusefs: fix another semi-infinite loop bug regarding signal handlingAlan Somers2019-07-181-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | fticket_wait_answer would spin if it received an unhandled signal whose default disposition is to terminate. The reason is because msleep(9) would return EINTR even for a masked signal. One reason is when the thread is stopped, which happens for example during sigexit(). Fix this bug by returning immediately if fticket_wait_answer ever gets interrupted a second time, for any reason. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350113
* | fusefs: multiple interruptility improvementsAlan Somers2019-07-171-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) Don't explicitly not mask SIGKILL. kern_sigprocmask won't allow it to be masked, anyway. 2) Fix an infinite loop bug. If a process received both a maskable signal lower than 9 (like SIGINT) and then received SIGKILL, fticket_wait_answer would spin. msleep would immediately return EINTR, but cursig would return SIGINT, so the sleep would get retried. Fix it by explicitly checking whether SIGKILL has been received. 3) Abandon the sig_isfatal optimization introduced by r346357. That optimization would cause fticket_wait_answer to return immediately, without waiting for a response from the server, if the process were going to exit anyway. However, it's vulnerable to a race: 1) fatal signal is received while fticket_wait_answer is sleeping. 2) fticket_wait_answer sends the FUSE_INTERRUPT operation. 3) fticket_wait_answer determines that the signal was fatal and returns without waiting for a response. 4) Another thread changes the signal to non-fatal. 5) The first thread returns to userspace. Instead of exiting, the process continues. 6) The application receives EINTR, wrongly believes that the operation was successfully interrupted, and restarts it. This could cause problems for non-idempotent operations like FUSE_RENAME. Reported by: kib (the race part) Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=350097
* | fusefs: fix the build with some NODEBUG kernelsAlan Somers2019-07-133-3/+3
| | | | | | | | | | | | | | | | | | systm.h needs to be included before counter.h Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349977
* | projects/fuse2: build fixesAlan Somers2019-07-131-1/+0
| | | | | | | | | | | | | | | | | | | | * 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: don't leak memory of unsent operations on unmountAlan Somers2019-06-281-0/+7
| | | | | | | | | | | | | | Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349513
* | [skip ci] update copyright headers in fusefs filesAlan Somers2019-06-2815-0/+75
| | | | | | | | | | | | | | Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349502
* | fusefs: fix a memory leak regarding FUSE_INTERRUPTAlan Somers2019-06-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | We were leaking the fuse ticket if the original operation completed before the daemon received the INTERRUPT operation. Fixing this was easier than I expected. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349473
* | fusefs: recycle vnodes after their last unlinkAlan Somers2019-06-272-30/+32
| | | | | | | | | | | | | | | | | | | | | | | | Previously fusefs would never recycle vnodes. After VOP_INACTIVE, they'd linger around until unmount or the vnlru reclaimed them. This commit essentially actives and inlines the old reclaim_revoked sysctl, and fixes some issues dealing with the attribute cache and multiply linked files. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349468
* | fusefs: counter(9) variables should not be statically initializedAlan Somers2019-06-272-3/+3
| | | | | | | | | | | | | | | | Reported by: rpokala Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349465
* | fusefs: convert statistical sysctls to use counter(9)Alan Somers2019-06-2710-35/+104
| | | | | | | | | | | | | | | | | | | | counter(9) is more performant than using atomic instructions to update sysctls that just report statistics to userland. Sponsored by: The FreeBSD Foundation Notes: svn path=/projects/fuse2/; revision=349462
generated by cgit v1.3 (git 2.53.0) at 2026-08-02 01:37:24 +0000