fusefs: make the tests more robust to changes to maxphys

Remove assumptions in two test cases that maxphys won't be huge.

Reported by: kib
MFC after: 2 weeks
Sponsored by: Axcient

tests/fusefs: fix all tests that depend on kern.maxphys

The tests try to read kern.maxphys sysctl into int value, while
unsigned long is required. Not sure when this was broken, seems like
since cd

tests/fusefs: fix all tests that depend on kern.maxphys

The tests try to read kern.maxphys sysctl into int value, while
unsigned long is required. Not sure when this was broken, seems like
since cd8537910406e.

Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D45053

show more ...

fusefs: prefer new/delete over malloc/free

MFC after: 2 weeks
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D43464

Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

fusefs tests: handle -Wdeprecated* issues with GoogleTest 1.14.0

`INSTANTIATE_TEST_CASE_P` has been replaced with `INSTANTIATE_TEST_SUITE_P`.
Replace all uses of the former macro with the latter mac

fusefs tests: handle -Wdeprecated* issues with GoogleTest 1.14.0

`INSTANTIATE_TEST_CASE_P` has been replaced with `INSTANTIATE_TEST_SUITE_P`.
Replace all uses of the former macro with the latter macro.

While here, address the fact that the latter macro doesn't permit some
of the constructions that the former macro did, e.g., empty parameters,
etc.

MFC after: 2 weeks
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D41398

show more ...

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

fusefs: fix a buffer overflow in the tests

The actual overflow occured in the ReadAhead.readahead test.
Surprisingly it has never segfaulted or resulted in any bad behavior.

MFC after: 1 week
Spons

fusefs: fix a buffer overflow in the tests

The actual overflow occured in the ReadAhead.readahead test.
Surprisingly it has never segfaulted or resulted in any bad behavior.

MFC after: 1 week
Sponsored by: Axcient
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38718

show more ...

fusefs: truncate write if it would exceed RLIMIT_FSIZE

PR: 164793
MFC after: 2 weeks
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D36703

fusefs: correctly handle servers that report too much data written

During a FUSE_WRITE, the kernel requests the server to write a certain
amount of data, and the server responds with the amount that

fusefs: correctly handle servers that report too much data written

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>
MFC after: 2 weeks
Sponsored by: Axcient
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D34955

show more ...

fusefs: Fix a bug during VOP_STRATEGY when the server changes file size

If the FUSE server tells the kernel that a file's size has changed, then
the kernel must invalidate any portion of that file i

fusefs: Fix a bug during VOP_STRATEGY when the server changes file size

If the FUSE server tells the kernel that a file's size has changed, then
the kernel must invalidate any portion of that file in cache. But the
kernel can't do that during VOP_STRATEGY, because the file's buffers are
already locked. Instead, proceed with the write.

PR: 256937
Reported by: Agata <chogata@moosefs.pro>
Tested by: Agata <chogata@moosefs.pro>
MFC after: 2 weeks
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D32332

show more ...

fusefs: reenable the WriteCluster.cluster_write_err test

The underlying panic was just fixed by
revision 27006229f7a40a18a61a0e8fd270bc583326b690

PR: 238565
MFC after: 1 week
MFC with: 27006229f7a

fusefs: reenable the WriteCluster.cluster_write_err test

The underlying panic was just fixed by
revision 27006229f7a40a18a61a0e8fd270bc583326b690

PR: 238565
MFC after: 1 week
MFC with: 27006229f7a40a18a61a0e8fd270bc583326b690

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: fix an expectation in one of the tests

An order-of-operations problem caused an expectation intended for
FUSE_READ to instead match FUSE_ACCESS. Surprisingly, only one test
case was affecte

fusefs: fix an expectation in one of the tests

An order-of-operations problem caused an expectation intended for
FUSE_READ to instead match FUSE_ACCESS. Surprisingly, only one test
case was affected.

MFC after: 2 weeks
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D27818

show more ...

fusefs: fix the tests for a wider range of maxphys

maxphys is now a tunable, ever since r368124. The default value is also
larger than it used to be. That broke several fusefs tests that made
assu

fusefs: fix the tests for a wider range of maxphys

maxphys is now a tunable, ever since r368124. The default value is also
larger than it used to be. That broke several fusefs tests that made
assumptions about maxphys.

* WriteCluster.clustering used the MAXPHYS compile-time constant.

* WriteBackAsync.direct_io_partially_overlaps_cached_block implicitly
depended on the default value of maxphys. Fix it by making the
dependency explicit.

* Write.write_large implicitly assumed that maxphys would be no more
than twice maxbcachebuf. Fix it by explicitly setting m_max_write.

* WriteCluster.clustering and several others failed because the MockFS
module did not work for max_write > 128KB (which most tests would set
when maxphys > 256KB). Limit max_write accordingly. This is the same
as fusefs-libs's behavior.

* Bmap's tests were originally written for MAXPHYS=128KB. With larger
values, the simulated file size was too small.

PR: 252096
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D27769

show more ...

fusefs tests: quell Coverity "Argument cannot be negative" warnings

Must abort tests early if open(2) fails.

Reported by: Coverity
Coverity CID: 1432810 and many others
Reviewed by: kevans
MFC afte

fusefs tests: quell Coverity "Argument cannot be negative" warnings

Must abort tests early if open(2) fails.

Reported by: Coverity
Coverity CID: 1432810 and many others
Reviewed by: kevans
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26635

show more ...

fusefs: fix mmap'd writes in direct_io mode

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

fusefs: fix mmap'd writes in direct_io mode

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

show more ...

Merge ^/head r357662 through r357854.

fusefs: fix some memory leaks in the tests.

Oddly, most of these were not detected by Coverity.

Reported by: Coverity (one of them, anyway)
Coverity CID: 1404490
MFC after: 2 weeks

Merge ^/head r351732 through r352104.

fusefs: coverity cleanup in the tests

Address the following defects reported by Coverity:

* Structurally dead code (CID 1404366): set m_quit before FAIL, not after

* Unchecked return value of sysc

fusefs: coverity cleanup in the tests

Address the following defects reported by Coverity:

* Structurally dead code (CID 1404366): set m_quit before FAIL, not after

* Unchecked return value of sysctlbyname (CID 1404321)

* Unchecked return value of stat(2) (CID 1404471)

* Unchecked return value of open(2) (CID 1404402, 1404529)

* Unchecked return value of dup(2) (CID 1404478)

* Buffer overflows. These are all false positives caused by the fact that
Coverity thinks I'm using a buffer to store strings, when in fact I'm
really just using it to store a byte array that happens to be initialized
with a string. I'm changing the type from char to uint8_t in the hopes
that it will placate Coverity. (CID 1404338, 1404350, 1404367, 1404376,
1404379, 1404381, 1404388, 1404403, 1404425, 1404433, 1404434, 1404474,
1404480, 1404484, 1404503, 1404505)

* False positive file descriptor leak. I'm going to try to fix this with
Coverity modeling, but I'll also change an EXPECT to ASSERT so we don't
perform meaningless assertions after the failure. (CID 1404320, 1404324,
1404440, 1404445).

* Unannotated file descriptor leak. This will be followed up by a Coverity
modeling change. (CID 1404326, 1404334, 1404336, 1404357, 1404361,
1404372, 1404391, 1404395, 1404409, 1404430, 1404448, 1404451, 1404455,
1404457, 1404458, 1404460)

* Uninitialized variables in C++ constructors (CID 1404327, 1404346). In the
case of m_maxphys, this actually led to part of the FUSE_INIT's response
being set to stack garbage during the WriteCluster::clustering test.

* Uninitialized sun_len field in struct sockaddr_un (CID 1404330, 1404371,
1404429).

Reported by: Coverity
Reviewed by: emaste
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21457

show more ...

fusefs: skip some tests when unsafe aio is disabled

MFC after: 15 days
MFC-With: r350665
Sponsored by: The FreeBSD Foundation

fusefs: add SVN Keywords to the test files

Reported by: SVN pre-commit hooks
MFC after: 15 days
MFC-With: r350665
Sponsored by: The FreeBSD Foundation

fusefs: skip some tests when unsafe aio is disabled

MFC after: 16 days
MFC-With: r350665
Sponsored by: The FreeBSD Foundation

fusefs: merge from projects/fuse2

This commit imports the new fusefs driver. It raises the protocol level
from 7.8 to 7.23, fixes many bugs, adds a test suite for the driver, and
adds many new featu

fusefs: merge from projects/fuse2

This commit imports the new fusefs driver. It raises the protocol level
from 7.8 to 7.23, fixes many bugs, adds a test suite for the driver, and
adds many new features. New features include:

* Optional kernel-side permissions checks (-o default_permissions)
* Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK
* Allow interrupting FUSE operations
* Support named pipes and unix-domain sockets in fusefs file systems
* Forward UTIME_NOW during utimensat(2) to the daemon
* kqueue support for /dev/fuse
* Allow updating mounts with "mount -u"
* Allow exporting fusefs file systems over NFS
* Server-initiated invalidation of the name cache or data cache
* Respect RLIMIT_FSIZE
* Try to support servers as old as protocol 7.4

Performance enhancements include:

* Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags
* Cache file attributes
* Cache lookup entries, both positive and negative
* Server-selectable cache modes: writethrough, writeback, or uncached
* Write clustering
* Readahead
* Use counter(9) for statistical reporting

PR: 199934 216391 233783 234581 235773 235774 235775
PR: 236226 236231 236236 236291 236329 236381 236405
PR: 236327 236466 236472 236473 236474 236530 236557
PR: 236560 236844 237052 237181 237588 238565
Reviewed by: bcr (man pages)
Reviewed by: cem, ngie, rpokala, glebius, kib, bde, emaste (post-commit
review on project branch)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Pull Request: https://reviews.freebsd.org/D21110

show more ...

fusefs: fix panic when writing with O_DIRECT and using writeback cache

When a fusefs file system is mounted using the writeback cache, the cache
may still be bypassed by opening a file with O_DIRECT

fusefs: fix panic when writing with O_DIRECT and using writeback cache

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

show more ...