| #
e043af9c
|
| 19-Sep-2025 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: fix a kernel panic regarding SCM_RIGHTS
If the last copy of an open file resides within the socket buffer of a unix-domain socket, then VOP_CLOSE will be called with no thread information.
fusefs: fix a kernel panic regarding SCM_RIGHTS
If the last copy of an open file resides within the socket buffer of a unix-domain socket, then VOP_CLOSE will be called with no thread information. Fix fusefs to handle that case, and add a regression test.
Also add a test case for writes to a file that lies within a sockbuf. Along with close, a write from the writeback cache is the only other operation I can think of that might apply to a file residing in a sockbuf.
PR: 289686 Reported by: iron.udjin@gmail.com MFC after: 1 week Sponsored by: ConnectWise Reviewed by: glebius, markj Differential Revision: https://reviews.freebsd.org/D52625
show more ...
|
| #
b2792a30
|
| 09-May-2024 |
Alan Somers <asomers@FreeBSD.org> |
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
|
| #
e9b411d2
|
| 06-May-2024 |
Gleb Smirnoff <glebius@FreeBSD.org> |
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 ...
|
| #
8bae22bb
|
| 15-Jan-2024 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: prefer new/delete over malloc/free
MFC after: 2 weeks Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D43464
|
| #
b3e76948
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
| #
811e0a31
|
| 08-Aug-2023 |
Enji Cooper <ngie@FreeBSD.org> |
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 ...
|
| #
4d846d26
|
| 10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
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 ...
|
| #
0c9df4af
|
| 22-Feb-2023 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
be280f60
|
| 25-Sep-2022 |
Alan Somers <asomers@FreeBSD.org> |
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
|
| #
3a1b3c6a
|
| 18-Apr-2022 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
032a5bd5
|
| 03-Oct-2021 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
425bbe9e
|
| 30-May-2021 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
92bbfe1f
|
| 29-Dec-2020 |
Alan Somers <asomers@gmail.com> |
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 ...
|
| #
ae39db74
|
| 29-Dec-2020 |
Alan Somers <asomers@gmail.com> |
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 ...
|
| #
f928dbcb
|
| 24-Dec-2020 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
d2621689
|
| 02-Oct-2020 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
a62772a7
|
| 24-Sep-2020 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
7ee7e409
|
| 12-Feb-2020 |
Alan Somers <asomers@FreeBSD.org> |
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
|
| #
8e765737
|
| 06-Sep-2019 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
dbee856a
|
| 13-Aug-2019 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: skip some tests when unsafe aio is disabled
MFC after: 15 days MFC-With: r350665 Sponsored by: The FreeBSD Foundation
|
| #
1fa8ebfb
|
| 13-Aug-2019 |
Alan Somers <asomers@FreeBSD.org> |
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
|
| #
c2265ae7
|
| 12-Aug-2019 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: skip some tests when unsafe aio is disabled
MFC after: 16 days MFC-With: r350665 Sponsored by: The FreeBSD Foundation
|
| #
669a092a
|
| 28-Jul-2019 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
5a0b9a27
|
| 20-Jul-2019 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: fix warnings in the tests reported by GCC
Sponsored by: The FreeBSD Foundation
|
| #
7fc0921d
|
| 26-Jun-2019 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: annotate deliberate file descriptor leaks in the tests
closing a file descriptor causes FUSE activity that is superfluous to the purpose of most tests, but would nonetheless require matching
fusefs: annotate deliberate file descriptor leaks in the tests
closing a file descriptor causes FUSE activity that is superfluous to the purpose of most tests, but would nonetheless require matching expectations. Rather than do that, most tests deliberately leak file descriptors instead. This commit moves the leakage from each test into two trivial functions: leak and leakdir. Hopefully Coverity will only complain about those functions and not all of their callers.
Sponsored by: The FreeBSD Foundation
show more ...
|