On 05/26/2017 04:11 PM, Nikolaus Rath wrote:
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?
If nothing is pending, it will go to pending queue immediately. But this
won't guarantee that the userspace fetches it before fuse_release() returns.
And how
can there be a pending request if the file isn't open anymore?
I think the comment tells us about pending request in general, not
specifically for that given file.
Best,
-Nikolaus
