fusefs: fix a dead store in fuse_vnop_advlock

kevans actually caught this in the original review and I fixed it, but
then I committed an older copy of the branch. Whoops.

Reported by: kevans
MFC a

fusefs: fix a dead store in fuse_vnop_advlock

kevans actually caught this in the original review and I fixed it, but
then I committed an older copy of the branch. Whoops.

Reported by: kevans
MFC after: 13 days
MFC with: 929acdb19acb67cc0e6ee5439df98e28a84d4772
Differential Revision: https://reviews.freebsd.org/D29031

show more ...

fusefs: fix two bugs regarding fcntl file locks

1) F_SETLKW (blocking) operations would be sent to the FUSE server as
F_SETLK (non-blocking).

2) Release operations, F_SETLK with lk_type = F_UNLC

fusefs: fix two bugs regarding fcntl file locks

1) F_SETLKW (blocking) operations would be sent to the FUSE server as
F_SETLK (non-blocking).

2) Release operations, F_SETLK with lk_type = F_UNLCK, would simply
return EINVAL.

PR: 253500
Reported by: John Millikin <jmillikin@gmail.com>
MFC after: 2 weeks

show more ...

Fix vnode locking bug in fuse_vnop_copy_file_range

MFC-With: 92bbfe1f0d1f1c4436d1f064a16e5aaf682526ba
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D27938

fusefs: only check vnode locks with DEBUG_VFS_LOCKS

MFC-With: 37df9d3bba8577fcdd63382ff5a4a5cbb4aa55b4
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D27939

Fix a vnode locking bug in fuse_vnop_advlock.

Must lock the vnode before accessing the fufh table. Also, check for
invalid parameters earlier. Bug introduced by r346170.

MFC after: 2 weeks

Revie

Fix a vnode locking bug in fuse_vnop_advlock.

Must lock the vnode before accessing the fufh table. Also, check for
invalid parameters earlier. Bug introduced by r346170.

MFC after: 2 weeks

Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D27936

show more ...

fusefs: implement FUSE_COPY_FILE_RANGE.

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 b

fusefs: implement FUSE_COPY_FILE_RANGE.

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

show more ...

fusefs: update FUSE protocol to 7.24 and implement FUSE_LSEEK

FUSE_LSEEK reports holes on fuse file systems, and is used for example
by bsdtar.

MFC after: 2 weeks
Relnotes: yes
Reviewed by: cem
Dif

fusefs: update FUSE protocol to 7.24 and implement FUSE_LSEEK

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

show more ...

Split out cwd/root/jail, cmask state from filedesc table

No functional change intended.

Tracking these structures separately for each proc enables future work to
correctly emulate clone(2) in linux

Split out cwd/root/jail, cmask state from filedesc table

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

show more ...

vfs: drop the de facto curthread argument from VOP_INACTIVE

fs: clean up empty lines in .c and .h files

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

fuse: unbreak after r364814

Reported by: kevans

vfs: remove the always-curthread td argument from VOP_RECLAIM

Fix issues with FUSE_ACCESS when default_permissions is disabled

This patch fixes two issues relating to FUSE_ACCESS when the
default_permissions mount option is disabled:

* VOP_ACCESS() calls with

Fix issues with FUSE_ACCESS when default_permissions is disabled

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

show more ...

fusefs: avoid cache corruption with buggy fuse servers

The FUSE protocol allows the client (kernel) to cache a file's size, if the
server (userspace daemon) allows it. A well-behaved daemon obviousl

fusefs: avoid cache corruption with buggy fuse servers

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

show more ...

Merge ^/head r357408 through r357661.

Provide O_SEARCH

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'v

Provide O_SEARCH

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

show more ...

vfs: flatten vop vectors

This eliminates the following loop from all VOP calls:

while(vop != NULL && \
vop->vop_spare2 == NULL && vop->vop_bypass == NULL)
vop = vop->vop_default;

Revie

vfs: flatten vop vectors

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

show more ...

Merge ^/head r352319 through r352435.

fusefs: fix some minor issues with fuse_vnode_setparent

* 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

fusefs: fix some minor issues with fuse_vnode_setparent

* 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

show more ...

Merge ^/head r351732 through r352104.

Coverity fixes in fusefs(5)

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 1404

Coverity fixes in fusefs(5)

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

show more ...

Merge ^/head r351317 through r351731.

Remove unused VM page locking macros.

They were orphaned by r292373.

Reviewed by: asomers
MFC after: 1 week
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D21469

Rework v_object lifecycle for vnodes.

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.

Rework v_object lifecycle for vnodes.

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

show more ...