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

[Nikolaus Rath <Nikolaus@rath.org>]

On May 31 2017, Maxim Patlasov <mpatlasov@virtuozzo.com> 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?

> 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...



Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«