fusefs: fix a cached attributes bug during directory rename

When renaming a directory into a different parent directory, invalidate
the cached attributes of the new parent. Otherwise, stat will sho

fusefs: fix a cached attributes bug during directory rename

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)

show more ...

fuse: Fix build on 32-bit architectures

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 d

fuse: Fix build on 32-bit architectures

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.

show more ...

Fix NFS exports of FUSE file systems for big directories

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
s

Fix NFS exports of FUSE file systems for big directories

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)

show more ...

fusefs: Address -Wunused-but-set-variable warnings

Reviewed by: asomers

(cherry picked from commit 3d8562348c9cf1a6bdc32382f5f45a0534da094a)

fusefs: implement VOP_ALLOCATE

Now posix_fallocate will be correctly forwarded to fuse file system
servers, for those that support it.

Reviewed by: pfg
Differential Revision: https://reviews.freebs

fusefs: implement VOP_ALLOCATE

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)

show more ...

fusefs: in the tests, always assume debug.try_reclaim_vnode is available

In an earlier version of the revision that created that sysctl (D20519)
the sysctl was gated by INVARIANTS, so the test had t

fusefs: in the tests, always assume debug.try_reclaim_vnode is available

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)

show more ...

fusefs: copy_file_range must update file timestamps

If FUSE_COPY_FILE_RANGE returns successfully, update the atime of the
source and the mtime and ctime of the destination.

Reviewers: pfg
Different

fusefs: copy_file_range must update file timestamps

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)

show more ...

Fix a race in fusefs that can corrupt a file's size.

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 serve

Fix a race in fusefs that can corrupt a file's size.

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 <[email protected]>
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D33158

(cherry picked from commit 13d593a5b060cf7be40acfa2ca9dc9e0e2339a31)

show more ...