| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Convert all the remaining users of fuse_session_loop_mt() to
the new 3.12 config api.
|
|
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.
|
|
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.
|
|
|
|
IN a bunch of comments we say 'under the terms of the GNU GPL', make
it clear this is GPLv2 (as LICENSE says).
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
|
|
|
|
|
|
Fix spelling errors
|
|
Fixes: #208.
|
|
|
|
update_fs_loop() is still running when the filesystem unmounts,
but it that case calls to fuse_lowlevel_notify_* will fail.
Fixes: #105.
|
|
|
|
Fixes: #81.
|
|
We now only list options that are potentially useful for an
end-user (and unlikely to accidentally break a file system). The full
list of FUSE options has been moved to the documentation of the
fuse_new() and fuse_session_new() functions.
|
|
Instead of using command line options to modify struct fuse_conn_info
before and after calling the init() handler, we now give the file system
explicit control over this.
|
|
This option really affects the behavior of the session loop, not the
low-level interface. Therefore, it does not belong in the fuse_session
object.
|
|
The fix in commit cf4159156b was incomplete. While some false positives
are caused by sleep() in the file system taking longer than expected,
there was also a race condition where the file system would run before
the contents are initialized properly.
|
|
|
|
I think this is the reason for a sporadic test failure, where
fuse_lowlevel_notify_store() fails.
|
|
This should make it more obvious at first glance what the different
examples do.
|
