On May 26 2017, David Butterfield <dab21774-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote:
>> 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?
>>
>> Furthermore, does the VFS call fuse_release() directly while handling
>> the close() syscall, or does this happen asynchronously later on?
>
> Does the comment in fuse_release_common (called by fuse_release)
> (Linux 4.4.0) answer this?
>
> 267 /*
> 268 * Normally this will send the RELEASE request, however if
> 269 * some asynchronous READ or WRITE requests are outstanding,
> 270 * the sending will be delayed.
> 271 *
> 272 * Make the release synchronous if this is a fuseblk mount,
> 273 * synchronous RELEASE is allowed (and desirable) in this case
> 274 * because the server can be trusted not to screw up.
> 275 */
It does give some indication, I'd rather have someone familiar with the
actual code confirm this.
Specifically, this says that if async read()/write() requests are
pending, the RELEASE will be delayed. But does this guarantee that
that if there are no pending requests it will not be delayed? And how
can there be a pending request if the file isn't open anymore?
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
