Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936089AbcKXJKs (ORCPT ); Thu, 24 Nov 2016 04:10:48 -0500 Received: from mail-oi0-f68.google.com ([209.85.218.68]:36496 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934150AbcKXJKq (ORCPT ); Thu, 24 Nov 2016 04:10:46 -0500 MIME-Version: 1.0 X-Originating-IP: [217.173.44.24] In-Reply-To: <87a8cp3i6o.fsf@thinkpad.rath.org> References: <87a8cp3i6o.fsf@thinkpad.rath.org> From: Miklos Szeredi Date: Thu, 24 Nov 2016 10:10:44 +0100 Message-ID: Subject: Re: [fuse-devel] fuse: feasible to distinguish between umount and abort? To: linux-kernel , linux-fsdevel , Miklos Szeredi , fuse-devel 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-Length: 1247 Lines: 29 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. Please file a bug somewhere. I don't mind if kernel bugs are also kept at the github project as long as they can easily be found. Thanks, Miklos