Re: [fuse-devel] fuse: when are release requests queued?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/31/2017 12:19 PM, Nikolaus Rath wrote:

On May 31 2017, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote:
Can someone tell me at which point the fuse kernel module will send a
RELEASE request to userspace?
Anytime after fuse_release(). It only puts request to background
queue. Later, the request will be transferred to pending queue. And
later, the userspace will fetch it by fuse_dev_do_read().

Is it possible that this is delayed until
after the close() syscall for the last fd has returned and userspace has
submitted a different fuse request for the same fs?
I think it's possible. See how flush_bg_queue() do nothing if
fc->active_background > fc->max_background.
Thanks Maxim! Not sure what I'd do with these issues without you :-).


Is there a way to deliberate trigger this behavior for debugging? For
example, is there a kernel equivalent of sleep(1) that I could put into
fuse_release()?
schedule_timeout_interruptible(HZ).
Hmm. I made the following change in linux 4.10:

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 2401c5..3568a8 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -252,6 +252,9 @@ void fuse_release_common(struct file *file, int opcode)
         if (unlikely(!ff))
                 return;
+ // Wait a little to force race condition in userspace
+        schedule_timeout_interruptible(1);
+
         req = ff->reserved_req;
         fuse_prepare_release(ff, file->f_flags, opcode);
But when doing e.g. "echo test > newfile", the RELEASE request still
comes right away (judging from the libfuse debugging output).

Do I need to do something else?

Try HZ*10 instead of 1 as an argument of schedule_timeout_interruptible.


But it's better to instrument fuse
userspace to postpone processing some i/o requests. Then you'll keep
fc->active_background > fc->max_background for a while. During that
period fuse_release may succeed with FUSE_RELEASE queued, but not
passed to the userspace. Then you cat try to sneak another request --
something not involving fuse background queue.
I don't know.. why is this better? It seems a lot more complicated. I
need to generate the extra request, add some switch to tell libfuse when
to start processing again, synchronize this with sneaking in the other
request...

I thought it's better because it would trigger delayed processing of FUSE_RELEASE: last __fput() succeeded, but fuse userspace will see FUSE_RELEASE only later. Adding sleep to fuse_release_common would only extend processing time of last __fput(), is that what you need?




Best,
-Nikolaus





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux