History log of /src/tests/sys/fs/fusefs/Makefile (Results 1 – 25 of 59)
Revision Date Author Comments
# 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


123