On 05/31/2017 01:31 PM, Nikolaus Rath wrote:
On May 31 2017, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote:
I do not fully understand the difference you describe. What I would like
to construct is the following scenario:
1. Userspace calls close()
2. Userspace close() returns
3. Userspace calls unlink()
4. Userspace unlink() returns
5. libfuse reads UNLINK request from kernel pipe
6. libfuse reads RELEASE request from kernel pipe
What would be the simplest way to do that?
I would try to keep fc->active_background elevated somehow. For
example you add sleep(1) for every incoming write request to libfuse
and serialize processing them. Then you generate enough writes to
achieve fc->max_background. If you call close() now, and if it really
ends up in last __fput(), corresponding FUSE_RELEASE will sit in
background queue for long while (as many seconds as # elements in the
queue). But close() from your 2. will return much earlier because it
doesn't wait for completion of FUSE_RELEASE. Hence unlink() might
succeed.
Ah, got it now, thanks!
Wouldn't be a simpler solution be to just patch the kernel module to
*always* put FUSE_RELEASE requests into the background queue, so that I
don't have to manually keep fc->active_background elevated?
I just can't seem to find the code that does this check... I would
expect it in fuse_file_put(), but the condition in there does not seem to
look at the number of background requests at all.
The decision is made at mount stage: it's either fuseblk mount or not.
If it's not fuseblk mount, the kernel always put FUSE_RELEASE to
background queue. And vice versa.
Keeping active_background elevated may help us to win the race: you want
unlink is queued and processed before the userspace reads FUSE_RELEASE
from kernel.
Best,
-Nikolaus
