History log of /freebsd/sys/fs/fuse/fuse_vnops.c (Results 151 – 175 of 239)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# fd2749f2 26-Mar-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: delete dead code

This change also inlines several previously #define'd symbols that didn't
really have the meanings indicated by the comments.

Sponsored by: The FreeBSD Foundation


# 19ef317d 23-Mar-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: fallback to MKNOD/OPEN if a filesystem doesn't support CREATE

If a FUSE filesystem returns ENOSYS for FUSE_CREATE, then fallback to
FUSE_MKNOD/FUSE_OPEN.

Also, fix a memory leak in the erro

fusefs: fallback to MKNOD/OPEN if a filesystem doesn't support CREATE

If a FUSE filesystem returns ENOSYS for FUSE_CREATE, then fallback to
FUSE_MKNOD/FUSE_OPEN.

Also, fix a memory leak in the error path of fuse_vnop_create. And do a
little cleanup in fuse_vnop_open.

PR: 199934
Reported by: samm@os2.kiev.ua
Sponsored by: The FreeBSD Foundation

show more ...


# bf4d7084 22-Mar-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: support VOP_MKNOD

PR: 236236
Sponsored by: The FreeBSD Foundation


# 6248288e 22-Mar-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: correctly handle cacheable negative LOOKUP responses

The FUSE protocol allows for LOOKUP to return a cacheable negative response,
which means that the file doesn't exist and the kernel can c

fusefs: correctly handle cacheable negative LOOKUP responses

The FUSE protocol allows for LOOKUP to return a cacheable negative response,
which means that the file doesn't exist and the kernel can cache its
nonexistence. As of this commit fusefs doesn't cache the nonexistence, but
it does correctly handle such responses. Prior to this commit attempting to
create a file, even with O_CREAT would fail with ENOENT if the daemon
returned a cacheable negative response.

PR: 236231
Sponsored by: The FreeBSD Foundation

show more ...


# 915012e0 22-Mar-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: Don't treat fsync the same as fdatasync

For an unknown reason, fusefs was _always_ sending the fdatasync operation
instead of fsync. Now it correctly sends one or the other.

Also, remove t

fusefs: Don't treat fsync the same as fdatasync

For an unknown reason, fusefs was _always_ sending the fdatasync operation
instead of fsync. Now it correctly sends one or the other.

Also, remove the Fsync.fsync_metadata_only test, along with the recently
removed Fsync.nop. They should never have been added. The kernel shouldn't
keep track of which files have dirty data; that's the daemon's job.

PR: 236473
Sponsored by: The FreeBSD Foundation

show more ...


# 90612f3c 21-Mar-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: VOP_FSYNC should be synchronous -- sometimes

I committed too hastily in r345390. There are cases, not directly reachable
from userland, where VOP_FSYNC ought to be asynchronous. This commi

fusefs: VOP_FSYNC should be synchronous -- sometimes

I committed too hastily in r345390. There are cases, not directly reachable
from userland, where VOP_FSYNC ought to be asynchronous. This commit fixes
fusefs to handle VOP_FSYNC synchronously if and only if the VFS requests it.

PR: 236474
X-MFC-With: 345390
Sponsored by: The FreeBSD Foundation

show more ...


# cc34f2f6 21-Mar-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: VOP_FSYNC should be synchronous

returning asynchronously pretty much defeats the point of fsync

PR: 236474
Sponsored by: The FreeBSD Foundation


# f9856d08 21-Mar-2019 Alan Somers <asomers@FreeBSD.org>

MFHead @345353


# 123af6ec 20-Mar-2019 Alan Somers <asomers@FreeBSD.org>

Rename fuse(4) to fusefs(4)

This makes it more consistent with other filesystems, which all end in "fs",
and more consistent with its mount helper, which is already named
"mount_fusefs".

Reviewed b

Rename fuse(4) to fusefs(4)

This makes it more consistent with other filesystems, which all end in "fs",
and more consistent with its mount helper, which is already named
"mount_fusefs".

Reviewed by: cem, rgrimes
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19649

show more ...


# 7e4844f7 19-Mar-2019 Alan Somers <asomers@FreeBSD.org>

fuse(4): remove more debugging printfs

I missed these in r344664. They're basically useless because they can only
be controlled at compile-time. Also, de-inline fuse_internal_cache_attrs.
It's big

fuse(4): remove more debugging printfs

I missed these in r344664. They're basically useless because they can only
be controlled at compile-time. Also, de-inline fuse_internal_cache_attrs.
It's big enough to be a regular function, and this way it gets a dtrace FBT
probe.

Sponsored by: The FreeBSD Foundation

show more ...


# 2aaf9152 18-Mar-2019 Alan Somers <asomers@FreeBSD.org>

MFHead@r345275


# ff511f1f 11-Mar-2019 Enji Cooper <ngie@FreeBSD.org>

MFhead@r344996


# e7df9886 06-Mar-2019 Conrad Meyer <cem@FreeBSD.org>

FUSE: Prevent trivial panic

When open(2) was invoked against a FUSE filesystem with an unexpected flags
value (no O_RDONLY / O_RDWR / O_WRONLY), an assertion fired, causing panic.

For now, prevent

FUSE: Prevent trivial panic

When open(2) was invoked against a FUSE filesystem with an unexpected flags
value (no O_RDONLY / O_RDWR / O_WRONLY), an assertion fired, causing panic.

For now, prevent the panic by rejecting such VOP_OPENs with EINVAL.

This is not considered the correct long term fix, but does prevent an
unprivileged denial-of-service.

PR: 236329
Reported by: asomers
Reviewed by: asomers
Sponsored by: Dell EMC Isilon

show more ...


# cf169498 28-Feb-2019 Alan Somers <asomers@FreeBSD.org>

fuse(4): convert debug printfs into dtrace probes

fuse(4) was heavily instrumented with debug printf statements that could
only be enabled with compile-time flags. They fell into three basic groups

fuse(4): convert debug printfs into dtrace probes

fuse(4) was heavily instrumented with debug printf statements that could
only be enabled with compile-time flags. They fell into three basic groups:

1) Totally redundant with dtrace FBT probes. These I deleted.
2) Print textual information, usually error messages. These I converted to
SDT probes of the form fuse:fuse:FILE:trace. They work just like the old
printf statements except they can be enabled at runtime with dtrace.
They can be filtered by FILE and/or by priority.
3) More complicated probes that print detailed information. These I
converted into ad-hoc SDT probes.

Sponsored by: The FreeBSD Foundation

show more ...


# 18b18078 25-Feb-2019 Enji Cooper <ngie@FreeBSD.org>

MFhead@r344527


# a8fe8db4 25-Feb-2019 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r344178 through r344512.


# 02295caf 20-Feb-2019 Conrad Meyer <cem@FreeBSD.org>

Fuse: whitespace and style(9) cleanup

Take a pass through fixing some of the most egregious whitespace issues in
fs/fuse. Also fix some style(9) warts while here. Not 100% cleaned up, but
somewhat

Fuse: whitespace and style(9) cleanup

Take a pass through fixing some of the most egregious whitespace issues in
fs/fuse. Also fix some style(9) warts while here. Not 100% cleaned up, but
somewhat less painful to look at and edit.

No functional change.

show more ...


# bd4cb2a4 20-Feb-2019 Conrad Meyer <cem@FreeBSD.org>

fuse: add descriptions for remaining sysctls

(Except reclaim revoked; I don't know what that goal of that one is.)


# 30e009fc 19-Feb-2019 Enji Cooper <ngie@FreeBSD.org>

MFhead@r344270


# 3c324b94 15-Feb-2019 Conrad Meyer <cem@FreeBSD.org>

FUSE: Refresh cached file size when it changes (lookup)

The cached fvdat->filesize is indepedent of the (mostly unused)
cached_attrs, and we failed to update it when a cached (but perhaps
inactive)

FUSE: Refresh cached file size when it changes (lookup)

The cached fvdat->filesize is indepedent of the (mostly unused)
cached_attrs, and we failed to update it when a cached (but perhaps
inactive) vnode was found during VOP_LOOKUP to have a different size than
cached.

As noted in the code comment, this can occur in distributed filesystems or
with other kinds of irregular file behavior (anything is possible in FUSE).

We do something similar in fuse_vnop_getattr already.

PR: 230258 (as reported in description; other issues explored in
comments are not all resolved)
Reported by: MooseFS FreeBSD Team <freebsd AT moosefs.com>
Submitted by: Jakub Kruszona-Zawadzki <acid AT moosefs.com> (earlier version)

show more ...


# 194e691a 15-Feb-2019 Conrad Meyer <cem@FreeBSD.org>

FUSE: Only "dirty" cached file size when data is dirty

Most users of fuse_vnode_setsize() set the cached fvdat->filesize and update
the buf cache bounds as a result of either a read from the underly

FUSE: Only "dirty" cached file size when data is dirty

Most users of fuse_vnode_setsize() set the cached fvdat->filesize and update
the buf cache bounds as a result of either a read from the underlying FUSE
filesystem, or as part of a write-through type operation (like truncate =>
VOP_SETATTR). In these cases, do not set the FN_SIZECHANGE flag, which
indicates that an inode's data is dirty (in particular, that the local buf
cache and fvdat->filesize have dirty extended data).

PR: 230258 (related)

show more ...


# 09176f09 15-Feb-2019 Conrad Meyer <cem@FreeBSD.org>

FUSE: Respect userspace FS "do-not-cache" of path components

The FUSE protocol demands that kernel implementations cache user filesystem
path components (lookup/cnp data) for a maximum period of tim

FUSE: Respect userspace FS "do-not-cache" of path components

The FUSE protocol demands that kernel implementations cache user filesystem
path components (lookup/cnp data) for a maximum period of time in the range
of [0, ULONG_MAX] seconds. In practice, typical requests are for 0, 1, or
10 seconds; or "a long time" to represent indefinite caching.

Historically, FreeBSD FUSE has ignored this client directive entirely. This
works fine for local-only filesystems, but causes consistency issues with
multi-writer network filesystems.

For now, respect 0 second cache TTLs and do not cache such metadata.
Non-zero metadata caching TTLs in the range [0.000000001, ULONG_MAX] seconds
are still cached indefinitely, because it is unclear how a userspace
filesystem could do anything sensible with those semantics even if
implemented.

Pass fuse_entry_out to fuse_vnode_get when available and only cache lookup
if the user filesystem did not set a zero second TTL.

PR: 230258 (inspired by; does not fix)

show more ...


# 78a7722f 15-Feb-2019 Conrad Meyer <cem@FreeBSD.org>

FUSE: Respect userspace FS "do-not-cache" of file attributes

The FUSE protocol demands that kernel implementations cache user filesystem
file attributes (vattr data) for a maximum period of time in

FUSE: Respect userspace FS "do-not-cache" of file attributes

The FUSE protocol demands that kernel implementations cache user filesystem
file attributes (vattr data) for a maximum period of time in the range of
[0, ULONG_MAX] seconds. In practice, typical requests are for 0, 1, or 10
seconds; or "a long time" to represent indefinite caching.

Historically, FreeBSD FUSE has ignored this client directive entirely. This
works fine for local-only filesystems, but causes consistency issues with
multi-writer network filesystems.

For now, respect 0 second cache TTLs and do not cache such metadata.
Non-zero metadata caching TTLs in the range [0.000000001, ULONG_MAX] seconds
are still cached indefinitely, because it is unclear how a userspace
filesystem could do anything sensible with those semantics even if
implemented.

In the future, as an optimization, we should implement notify_inval_entry,
etc, which provide userspace filesystems a way of evicting the kernel cache.

One potentially bogus access to invalid cached attribute data was left in
fuse_io_strategy. It is restricted behind the undocumented and non-default
"vfs.fuse.fix_broken_io" sysctl or "brokenio" mount option; maybe these are
deadcode and can be eliminated?

Some minor APIs changed to facilitate this:

1. Attribute cache validity is tracked in FUSE inodes ("fuse_vnode_data").

2. cache_attrs() respects the provided TTL and only caches in the FUSE
inode if TTL > 0. It also grows an "out" argument, which, if non-NULL,
stores the translated fuse_attr (even if not suitable for caching).

3. FUSE VTOVA(vp) returns NULL if the vnode's cache is invalid, to help
avoid programming mistakes.

4. A VOP_LINK check for potential nlink overflow prior to invoking the FUSE
link op was weakened (only performed when we have a valid attr cache). The
check is racy in a multi-writer network filesystem anyway -- classic TOCTOU.
We have to trust any userspace filesystem that rejects local caching to
account for it correctly.

PR: 230258 (inspired by; does not fix)

show more ...


# 756a5412 15-Jan-2019 Gleb Smirnoff <glebius@FreeBSD.org>

Allocate pager bufs from UMA instead of 80-ish mutex protected linked list.

o In vm_pager_bufferinit() create pbuf_zone and start accounting on how many
pbufs are we going to have set.
In variou

Allocate pager bufs from UMA instead of 80-ish mutex protected linked list.

o In vm_pager_bufferinit() create pbuf_zone and start accounting on how many
pbufs are we going to have set.
In various subsystems that are going to utilize pbufs create private zones
via call to pbuf_zsecond_create(). The latter calls uma_zsecond_create(),
and sets a limit on created zone. After startup preallocate pbufs according
to requirements of all pbuf zones.

Subsystems that used to have a private limit with old allocator now have
private pbuf zones: md(4), fusefs, NFS client, smbfs, VFS cluster, FFS,
swap, vnode pager.

The following subsystems use shared pbuf zone: cam(4), nvme(4), physio(9),
aio(4). They should have their private limits, but changing that is out of
scope of this commit.

o Fetch tunable value of kern.nswbuf from init_param2() and while here move
NSWBUF_MIN to opt_param.h and eliminate opt_swap.h, that was holding only
this option.
Default values aren't touched by this commit, but they probably should be
reviewed wrt to modern hardware.

This change removes a tight bottleneck from sendfile(2) operation, that
uses pbufs in vnode pager. Other pagers also would benefit from faster
allocation.

Together with: gallatin
Tested by: pho

show more ...


# cc426dd3 11-Dec-2018 Mateusz Guzik <mjg@FreeBSD.org>

Remove unused argument to priv_check_cred.

Patch mostly generated with cocinnelle:

@@
expression E1,E2;
@@

- priv_check_cred(E1,E2,0)
+ priv_check_cred(E1,E2)

Sponsored by: The FreeBSD Foundation


12345678910