This reconfigure is recommended to ensure the build system
(ninja/cmake/...) get the updated meson config. They
typically do, but it depends on file time stamps - is
a potential random error source.
Commit b1cdc497 ("ci-build.sh: Run ASAN and UBSAN at the same time")
also accidentally removed the test for versioned symbols.
Also export clang/clang++ to make sure new shells get it.
This was stalling - easier to check what happens
when it fails fast. And in general, sanitized
builds are faster than valgrind and detect almost
as much errors as valgrind (same level would be
achieved with MSAN, but that is hard to use),
so failures can be detected faster whan sanitizers
run first.
As noticed by valgrind in issue #907 example/poll.c
triggers a use-after-free
==85200== Thread 2:
==85200== Invalid read of size 4
==85200== at 0x485E54A: send_notify_iov (fuse_lowlevel.c:2267)
==85200== by 0x485E54A: fuse_lowlevel_notify_poll (fuse_lowlevel.c:2289)
==85200== by 0x1096F2: fsel_producer (poll.c:245)
==85200== by 0x4897EA6: start_thread (pthread_create.c:477)
==85200== by 0x49ADA6E: clone (clone.S:95)
==85200== Address 0x5291d68 is 392 bytes inside a block of size 920 free'd
==85200== at 0x48399AB: free (vg_replace_malloc.c:538)
==85200== by 0x485A12C: fuse_destroy (fuse.c:5103)
==85200== by 0x486220F: fuse_main_real (helper.c:389)
==85200== by 0x1091D6: main (poll.c:288)
==85200== Block was alloc'd at
==85200== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==85200== by 0x485BAA0: fuse_session_new (fuse_lowlevel.c:3036)
==85200== by 0x4859AF2: fuse_new@@FUSE_3.1 (fuse.c:4966)
==85200== by 0x4862129: fuse_main_real (helper.c:345)
==85200== by 0x1091D6: main (poll.c:288)
Issue is that the "fsel_producer" thread is still active after
fuse_destroy - it gets destructed too late.
Tests were failing because mount dir was missing.
Unclear to me why this became only recently an issue
(github internal - out of the sudden tests were hanging).
We want to see errors - reduce allowed errors.
With --maxfail=99 tests out of the sudden started to hang
in github, without a change in libfuse (I had actually tested
to previous release tags). With --maxfail=1 pytest aborts
and we see failing github.
Also increase python log level to NOTSET - NOTSET should print
all messages.
Also use "pytest" has wrapper for "python3 -m"
As per pull #898, fusermount3 had a severe issue that
should have been detected by ASAN. I guess tests used
the system default and not the sanitized binary.
Order of execution of fusermount3 is to try
1) full install path
if that fails
2) just fusermount3
So tests should be fixed by installing libfuse, setting the s-bit
on fusermount3 and then to run the tests.
- This adds a wrapper function for the call sequence
of posix_spawn and posix_spawnp.
- Replaces perror() with fuse_log - the latter
can be redirected through the file system log function
and gives better end user friendly output
- other minor changes, like variable renames
- no functional change
Client code might allocate a lot of memory before starting the mount.
Fork is slow for processes that are using a lot of memory. But
posix_spawn fixes that.
Another issue with fork is if the process is also doing RDMA - this
might lead to data corruption, as least if memory used for RDMA
is not marked with MADV_DONTFORK. At least with linux kernels
before 5.12.
Also see https://blog.nelhage.com/post/a-cursed-bug/ for more details
Change by Bernd:
This also prepares the new fusermount option "--comm-fd", but keeps
the previous way to pass the parameter as env variable. In a future
release (exact data to be determined) we are going to remove usage
of the env variable and will switch to the new parameter.
Commit 74b1df2e introduced a heap-buffer-overflow, as
allocated memory was not initialized and extract_x_options
was also not checking for the remaining buffer size.
Fix is to initialize the buffer and to also not exceed the buffer
size. Actually not exceeding buffer size is rather complex with C
and introduced quite some code changes.
Also fixed is a memory leak of allocated buffers in the commit
mentioned above.
This test was racy, the lookup counter must only be increased once
kernel side has lookup completed and knows about the inode.
However, this is still racy as
app thread
(python script) kernel-side libfuse thread kernel
----------------------------------------------------------------------
open file
lookup req
wait
handle req
reply
wake app thread
return
new_inode()
<continue file open>
So actually on libfuse side even after returning from kernel side
it is not ensured that the kernel has created the inode. I.e.
using lookup_cnt in the test is still racy.
A new variabled 'open_cnt' is added that is only increased in open
Using open_cnt should be safe to use as kernel side (with atomic-open)
first does lookup, from that data creates the inode and only then sends
an open request. I.e. update_fs_loop() must only call
fuse_lowlevel_notify_store() once it is absolutely sure kernel side has
created the inode (open_cnt) and when it is sure the kernel inode still
exists (lookup_cnt).
Not really nice, but we actually need to accept some errors, as
these still come up at umount time. Typically it is hard to hit,
but tests in github actually frequently get it. Actually, it can be
easily reproduced by commenting out the sleep line in
update_fs_loop(). Underlying issue is that kernel side is
sending ->destroy() only when it already internally released all
inodes - too late for this test. The errors I run into are ENOENT
and EBADFD, but I added back in ENODEV for safety.
In order to avoid any other kind races mutex lock is also introduced.
This test could fail whenever a something (kernel, userspace) decides
to flush in between of two 2048B writes. These two writes are supposed
to be merged into a single 4906 byte write by the kernel writeback cache,
but _sometimes_ the test fails because 2048 byte writes get through.
Fixes#882
Solution here is a modification how the test works - instead
of requiring an exact aggregation of 2x2048B into 4096B,
it now writes 64x2048B and requires in write-back modes
the number of received writes requests is lower than 64 - we
can expect that at least some writes get aggregated, but we do
know how many.
Co-authored-by: Bernd Schubert <bschubert@ddn.com>
Shared locks (parallel_direct_writes) cannot be enabled for O_DIRECT, as
O_DIRECT may be set past file open time with fcntl(fd, F_SETFD, ...).
Kernel side fuse has precautions for shared lock direct-IO (direct_io in
libfuse), as it needs an exclusive inode lock when direct and page cache
IO happend at the same time.
In order to enjoy the parallel_direct_writes feature (i.e., get a shared
lock, not exclusive lock) for writes to the same file), direct_io is needed.
The feature direct_io is corresponding to FOPEN_DIRECT_IO in fuse kernel.
FOPEN_DIRECT_IO and O_DIRECT are not entirely the same as described above.
So enable direct_io (i.e., FOPEN_DIRECT_IO in fuse kernel) to enjoy parallel
direct_writes.
Some patches related to FOPEN_DIRECT_IO and O_DIRECT are below:
https://lore.kernel.org/all/753d6823-e984-4730-a126-d66b65ea772c@ddn.com
This implements #651, tested with bindfs.
"x-*" options are comments meant to be interpreted by userspace.
#651 is about some 3rd party mount options like 'x-gvfs-notrash'.
This also removes the test if /etc/mtab is a symlink.
This test was added in commit 5f28cd15ab
and the corresponding ChangeLog entry in this commit points to mount
issues for read-only mtab.
However, in all recent Linux distributions /etc/mtab is a symlink to
/proc/self/mounts and never writable. In fact, util-linux 2.39
(libmount) entirely removed support for a writable mtab.
At least since util-linux 2.19 (10-Feb-2011) /run/mount/utab is used
as replacement for userspace mount entries..
Move the parallel_direct_writes enable action to the init function in high level API,
it is more recommended just like commit 8ee553dac. Besides, add some comments to show
that the feature parallel_direct_writes is depend on the feature direct_io (refer to
kernel side patch series to consolidate direct IO, link: https://lwn.net/ml/linux-fsdevel/20230918150313.3845114-1-bschubert@ddn.com for the reason).
'FUSE_CAP_HANDLE_KILLPRIV' is not enabled by default anymore, as that
would be a sudden security issue introduced by a new ABI and API
compatible libfuse version.
Allowing parallel dir operations could result in a crash in a filesystem
implementation that is not prepared for this.
To be safe keep this flag off by default (this is not a regression, since
there was no public release where this flag wasn't ignored).
If the filesystem wants better performance, then it should set this flag
explicitly.
Fixes: c9905341ea ("Pass FUSE_PARALLEL_DIROPS to kernel (#861)")
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
This is not called FUSE_CAP_DIRECT_IO_RELAX, as the kernel flag
FUSE_DIRECT_IO_RELAX is supposed to be renamed to
FUSE_DIRECT_IO_ALLOW_MMAP. The corresponding kernel patches just
did not land yet.
On shutdown update_fs_loop() was failing frequently in github
test with ENOENT, but only ENODEV was tested for and only for the.
With clean shutdown there is no need to test for such errors at all.
The original docstring was confusing; it was not clear that the ph must
be retained indefinitely, nor was it clear that the client *also* needs
to reply to the poll call immediately.
Clarify this by explaining that it is only necessary to retain a single
handle, that the client must retain ph, and that it must immediately
call reply.
This tells the kernel that parallel lookup/readdir operations are
supported. This is enabled by default but was not passed to the kernel
so you always get the synchronized version.
Since open(2) has been called with O_CLOEXEC flag if defined.
Signed-off-by: Xiaoguang Wang <lege.wang@jaguarmicro.com>
Co-authored-by: Xiaoguang Wang <lege.wang@jaguarmicro.com>
All these passthrough examples don't need writes to be serialized.
Actually, most file systems probably handle non serialized parallel
direct writes - the FOPEN_PARALLEL_DIRECT_WRITES flag is just
to avoid a regression for those file system that rely on serialized
DIO writes in fuse kernel. Passthrough file system forward the IO
to another file system, which actually handles that internally -
serialized in fuser kernel is not needed.
ix passthrough mount helper for running xfstests
* The mount helper does not see the env vars exported by xfstests
* Use the NFS style format TEST_DEV=source:/$TEST_SOURCE to communicate
the sourse path to the mount helper without confusing xfstest
* Also recognise when source= is provided in mount options
* Support -o remount (e.g. for test generic/306)
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Co-authored-by: Bernd Schubert <bschubert@ddn.com>
Co-authored-by: Amir Goldstein <amir73il@gmail.com>
Co-authored-by: Nikolaus Rath <Nikolaus@rath.org>
