Hi Maxim, On May 26 2017, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote: > On 05/25/2017 04:08 PM, Nikolaus Rath wrote: > >> Hello, >> >> I am trying to debug a sporadic test failure in libfuse >> (https://github.com/libfuse/libfuse/issues/157). >> >> >> 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()? >> Looking at fs/fuse/file.c, it looks as if fuse_release() directly calls >> fuse_request_send_background() to send the request. But at that point I >> can no longer follow the code. Is it possible for another request to >> sneak in at this point? > > Yes, but not for that given fuse_file that we're closing now. I assume that a fuse_file refers to the (formerly) opened file, right? So e.g. a unlink() request for the same directly entry could still go through before RELEASE has been transferred to the pending queue? Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
