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.
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
