Re: [fuse-devel] fuse: feasible to distinguish between umount and abort?

From: Nikolaus Rath
Date: Tue Nov 29 2016 - 11:01:26 EST

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
>>>> 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)?


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.Â