| #
da59b314
|
| 25-Jan-2026 |
Enji Cooper <ngie@FreeBSD.org> |
Account for the ctl test needing the ctl(4) module
This testcase does not function unless the /dev/ctl/... node exists, which is created by the ctl(4) module. Require the ctl(4) module to be loaded
Account for the ctl test needing the ctl(4) module
This testcase does not function unless the /dev/ctl/... node exists, which is created by the ctl(4) module. Require the ctl(4) module to be loaded so the test can be executed.
MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D54518
show more ...
|
| #
17ba6f42
|
| 05-Jul-2025 |
CismonX <admin@cismon.net> |
fusefs: support FUSE_IOCTL
MFC After: 1 week Signed-off-by: CismonX <admin@cismon.net> Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1470
|
| #
47015e45
|
| 07-Jan-2026 |
Jose Luis Duran <jlduran@FreeBSD.org> |
tests: Increase timeout
Bump the timeout value, to avoid cutoff on emulated architectures on ci.freebsd.org.
Reported by: Jenkins Reviewed by: ngie MFC after: 1 week Differential Revision: https://
tests: Increase timeout
Bump the timeout value, to avoid cutoff on emulated architectures on ci.freebsd.org.
Reported by: Jenkins Reviewed by: ngie MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D54550
show more ...
|
| #
2662fd6a
|
| 22-Jul-2025 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: report that all tests require the fusefs kernel module
Previously the googletest tests would skip themselves if /dev/fuse could not be found. But that information would not be passed to Kyu
fusefs: report that all tests require the fusefs kernel module
Previously the googletest tests would skip themselves if /dev/fuse could not be found. But that information would not be passed to Kyua. Instead it would think that they had passed. Also, the atf-sh test would previously fail if the fusefs module weren't loaded. Now both tests will correctly report their requirements to Kyua.
Note that fusefs's googletest tests still require that the mac_bsdextended(4) module _not_ be loaded, but Kyua has no way to report such a requirement.
MFC after: 2 weeks Sponsored by: ConnectWise Reviewed by: Siva Mahadevan <me@svmhdvn.name> Pull Request: https://github.com/freebsd/freebsd-src/pull/1782
show more ...
|
| #
9350e923
|
| 18-Dec-2024 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: fix a panic in vop_close with a CTL consumer
Kernel consumers like CTL may lack ucred objects. That led to a panic when CTL closed a fuse file, if atime was enabled on the mountpoint. Fix i
fusefs: fix a panic in vop_close with a CTL consumer
Kernel consumers like CTL may lack ucred objects. That led to a panic when CTL closed a fuse file, if atime was enabled on the mountpoint. Fix it by checking the ucred during close.
PR: 283402 MFC after: 2 weeks Sponsored by: ConnectWise Differential Revision: https://reviews.freebsd.org/D48165
show more ...
|
| #
cc9c2130
|
| 05-Jun-2025 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: Fix a panic when unmounting before init
fusefs would page fault due to the following sequence of events: * The server did not respond to FUSE_INIT in timely fashion. * Some other process tri
fusefs: Fix a panic when unmounting before init
fusefs would page fault due to the following sequence of events: * The server did not respond to FUSE_INIT in timely fashion. * Some other process tried to do unmount. * That other process got killed by a signal. * The server finally responded to FUSE_INIT.
PR: 287438 MFC after: 2 weeks Sponsored by: ConnectWise Reviewed by: arrowd Differential Revision: https://reviews.freebsd.org/D50799
show more ...
|
| #
cda23fc3
|
| 22-Apr-2025 |
Brooks Davis <brooks@FreeBSD.org> |
Move mntopts(3) suppport into libutil
Many programs use this functionality so it should be available centrally rather than compiled into each program independently. This has the modest downside of
Move mntopts(3) suppport into libutil
Many programs use this functionality so it should be available centrally rather than compiled into each program independently. This has the modest downside of adding libutil dependencies to some mount_<foo> programs, but many (plus mount(8)) already have those depndencies so this shouldn't be a major imposition.
In commit 906c312bbf74, Kirk said this could be done once the change was merged to FreeBSD 13. That happened in commit 668dfa016698 in 2023.
While here perform related tidying including removing SRCS where the only entry is ${PROG}.c rendering it unnecessary.
Reviewed by: olce, dim, emaste Differential Revision: https://reviews.freebsd.org/D49951
show more ...
|
| #
6527682a
|
| 11-Apr-2025 |
John Baldwin <jhb@FreeBSD.org> |
src: Use gnu++17 as the default C++ standard
Previously the compiler's default C++ standard was used unlike C where bsd.sys.mk explicitly sets a default language version. Setting an explicit defaul
src: Use gnu++17 as the default C++ standard
Previously the compiler's default C++ standard was used unlike C where bsd.sys.mk explicitly sets a default language version. Setting an explicit default version will give a more uniform experience across different compilers and compiler versions.
gnu++17 was chosen to match the default C standard. It is well supported by a wide range of clang (5+) and GCC (9+) versions.
gnu++17 is also the default C++ standard in recent versions of clang (16+) and GCC (11+). As a result, many of the explicit CXXSTD settings in Makefiles had the effect of lowering the C++ standard instead of raising it as was originally intended and are removed.
Note that the remaining explicit CXXSTD settings for atf and liblutok explicitly lower the standard to C++11 due to use of the deprecated auto_ptr<> template which is removed in later versions.
Reviewed by: imp, asomers, dim, emaste Differential Revision: https://reviews.freebsd.org/D49223
show more ...
|
| #
53f73aaf
|
| 18-Dec-2024 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: delete a comment in the tests
Even on a riscv embedded system, the fusefs tests run fast enough that 10 seconds is a reasonable timeout.
[skip ci]
MFC after: 2 weeks Sponsored by: ConnectW
fusefs: delete a comment in the tests
Even on a riscv embedded system, the fusefs tests run fast enough that 10 seconds is a reasonable timeout.
[skip ci]
MFC after: 2 weeks Sponsored by: ConnectWise
show more ...
|
| #
e9ac4169
|
| 15-Jul-2024 |
Warner Losh <imp@FreeBSD.org> |
Remove residual blank line at start of Makefile
This is a residual of the $FreeBSD$ removal.
MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix
|
| #
dc0b4094
|
| 21-Dec-2023 |
Dimitry Andric <dim@FreeBSD.org> |
Silence VLA extension warnings in fusefs tests
Building tests/sys/fs/fusefs with clang 18 results the following warning:
tests/sys/fs/fusefs/cache.cc:145:14: error: variable length arrays in C++
Silence VLA extension warnings in fusefs tests
Building tests/sys/fs/fusefs with clang 18 results the following warning:
tests/sys/fs/fusefs/cache.cc:145:14: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension] 145 | uint8_t buf[bufsize]; | ^~~~~~~
Because we do not particularly care that this is a clang extension, suppress the warning.
MFC after: 3 days
show more ...
|
| #
d0b2dbfa
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
| #
062de1c5
|
| 20-Jun-2023 |
John Baldwin <jhb@FreeBSD.org> |
tests/fusefs: Suppress false warning from GCC.
GCC complains that DNAME in the inval_entry_below_root test is not used, but EXPECT_LOOKUP() does pass DNAME to strcmp in an internal lambda function.
tests/fusefs: Suppress false warning from GCC.
GCC complains that DNAME in the inval_entry_below_root test is not used, but EXPECT_LOOKUP() does pass DNAME to strcmp in an internal lambda function.
Reviewed by: asomers Differential Revision: https://reviews.freebsd.org/D40661
show more ...
|
| #
5f51c9c3
|
| 21-Feb-2023 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: add some more test cases for bad fuse servers
MFC after: 1 week Sponsored by: Axcient Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D38719
|
| #
398c88c7
|
| 01-Jan-2022 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: implement VOP_ALLOCATE
Now posix_fallocate will be correctly forwarded to fuse file system servers, for those that support it.
MFC after: 2 weeks Reviewed by: pfg Differential Revision: htt
fusefs: implement VOP_ALLOCATE
Now posix_fallocate will be correctly forwarded to fuse file system servers, for those that support it.
MFC after: 2 weeks Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33389
show more ...
|
| #
13d593a5
|
| 29-Nov-2021 |
Alan Somers <asomers@FreeBSD.org> |
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 <chogata@moosefs.pro> Reviewed by: pfg MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D33158
show more ...
|
| #
5a3a8cb0
|
| 27-Aug-2021 |
Dimitry Andric <dim@FreeBSD.org> |
Silence more gtest warnings, now in fusefs tests
Follow-up d396c67f26b0 by also silencing warnings about deprecated implicit copy constructors in the fusefs tests, which use googletest.
Fixes: d39
Silence more gtest warnings, now in fusefs tests
Follow-up d396c67f26b0 by also silencing warnings about deprecated implicit copy constructors in the fusefs tests, which use googletest.
Fixes: d396c67f26b0 MFC after: 3 days
show more ...
|
| #
71befc35
|
| 12-Feb-2021 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: set d_off during VOP_READDIR
This allows d_off to be used with lseek to position the file so that getdirentries(2) will return the next entry. It is not used by readdir(3).
PR: 253411 Rep
fusefs: set d_off during VOP_READDIR
This allows d_off to be used with lseek to position the file so that getdirentries(2) will return the next entry. It is not used by readdir(3).
PR: 253411 Reported by: John Millikin <jmillikin@gmail.com> Reviewed by: cem MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D28605
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 ...
|
| #
37df9d3b
|
| 29-Dec-2020 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
7cc42f6d
|
| 01-Oct-2020 |
Kyle Evans <kevans@FreeBSD.org> |
Do a sweep and remove most WARNS=6 settings
Repeating the default WARNS here makes it slightly more difficult to experiment with default WARNS changes, e.g. if we did something absolutely bananas an
Do a sweep and remove most WARNS=6 settings
Repeating the default WARNS here makes it slightly more difficult to experiment with default WARNS changes, e.g. if we did something absolutely bananas and introduced a WARNS=7 and wanted to try lifting the default to that.
Drop most of them; there is one in the blake2 kernel module, but I suspect it should be dropped -- the default WARNS in the rest of the build doesn't currently apply to kernel modules, and I haven't put too much thought into whether it makes sense to make it so.
show more ...
|
| #
b0ecfb42
|
| 11-Mar-2020 |
Alan Somers <asomers@FreeBSD.org> |
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 ...
|
| #
4a045a66
|
| 09-Aug-2019 |
Brooks Davis <brooks@FreeBSD.org> |
Don't add -Wno-class-memaccess with older gcc.
This is a gcc 8.0+ warning which needed to be silenced on for the riscv build. amd64-xtoolchain-gcc still uses gcc 6.4.0 and does not understand this
Don't add -Wno-class-memaccess with older gcc.
This is a gcc 8.0+ warning which needed to be silenced on for the riscv build. amd64-xtoolchain-gcc still uses gcc 6.4.0 and does not understand this flag.
Reviewed by: asomers Feedback from: imp Differential Revision: https://reviews.freebsd.org/D21195
show more ...
|
| #
9f13765e
|
| 30-Jul-2019 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: fix building tests with GCC 8
GCC 8 objected to including C++-only flags in CWARNFLAGS
Sponsored by: The FreeBSD Foundation
|
| #
5a0b9a27
|
| 20-Jul-2019 |
Alan Somers <asomers@FreeBSD.org> |
fusefs: fix warnings in the tests reported by GCC
Sponsored by: The FreeBSD Foundation
|