On Nov 29 2016, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Fri, Nov 25, 2016 at 1:33 AM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
>> On Nov 24 2016, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>>> On Thu, Nov 24, 2016 at 12:11 AM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
>>>> Hello,
>>>>
>>>> Currently, both a call to umount(2) and writing "1" to
>>>> /sys/fs/fuse/connections/NNN/abort will put the /dev/fuse fd into the
>>>> same state: reading from it returns ENODEV, and polling on it returns
>>>> POLLERR.
>>>>
>>>> This causes problems for filesystems that want to ensure that the
>>>> mountpoint is free when they exit. If accessing the device fd gives the
>>>> above errors, they have to do an additional check to determine if they
>>>> still need to unmount the mountpoint. This is difficult to do without
>>>> race conditions (think of someone unmounting and immediately re-starting
>>>> a new filesystem instance).
>>>>
>>>> Would it be possible to change the behavior of the /dev/fuse fd so that
>>>> userspace can distinguish between a regular umount and use of the
>>>> /sys/fs/fuse abort)?
>>>
>>> Yes. My proposal would be for the kernel to send FUSE_DESTROY
>>> asynchronously and only return ENODEV once that request was read by
>>> userspace. Currently FUSE_DESTROY is sent synchronously for fuseblk
>>> mounts, but not for plain fuse mounts.
>>
>> I trust that this is a good plan, but from the description I can't quite
>> tell how the filesystem would make the distinction between umount/abort
>> based on this. Would FUSE_DESTROY be send only for unmount, but not for
>> abort?
>
> Right. The userspace implementation would need to be careful to
> process the DESTROY message before ENODEV received in a different
> thread. Maybe instead userspace and kernel should negotiate in INIT
> whether userspace wants a DESTROY or not. If it does, then on umount
> kernel sends DESTROY and does not return ENODEV. If userspace does
> not want DESTROY then it falls back to the old way of returning
> ENODEV. And on abort it would do that as well, regardless of the
> negotiated DESTROY request.
That sounds great to me. Would you have to implement this, or should I
try to give it a shot? In the latter case, could you give me a hint
where the entry points for the umount and abort code paths are (in the
kernel code)?
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
