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
