Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756443AbcK2QBX (ORCPT ); Tue, 29 Nov 2016 11:01:23 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:53488 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752161AbcK2QBO (ORCPT ); Tue, 29 Nov 2016 11:01:14 -0500 X-ME-Sender: X-Sasl-enc: EzMf9/ytQC7IiKkbQUxWZ7vcUo6hGCEYWrTu1RoN0M5j 1480435273 From: Nikolaus Rath To: Miklos Szeredi Cc: linux-kernel , linux-fsdevel , Miklos Szeredi , fuse-devel Subject: Re: [fuse-devel] fuse: feasible to distinguish between umount and abort? References: <87a8cp3i6o.fsf@thinkpad.rath.org> <87polkv1nr.fsf@vostro.rath.org> Mail-Copies-To: never Mail-Followup-To: Miklos Szeredi , linux-kernel , linux-fsdevel , Miklos Szeredi , fuse-devel Date: Tue, 29 Nov 2016 08:01:11 -0800 In-Reply-To: (Miklos Szeredi's message of "Tue, 29 Nov 2016 11:45:25 +0100") Message-ID: <87k2bm46ns.fsf@thinkpad.rath.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uATG1QB7023141 Content-Length: 2564 Lines: 55 On Nov 29 2016, Miklos Szeredi wrote: > On Fri, Nov 25, 2016 at 1:33 AM, Nikolaus Rath wrote: >> On Nov 24 2016, Miklos Szeredi wrote: >>> On Thu, Nov 24, 2016 at 12:11 AM, Nikolaus Rath 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.«