Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751569AbaJRSBQ (ORCPT ); Sat, 18 Oct 2014 14:01:16 -0400 Received: from mail-qa0-f42.google.com ([209.85.216.42]:59457 "EHLO mail-qa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751515AbaJRSBO (ORCPT ); Sat, 18 Oct 2014 14:01:14 -0400 MIME-Version: 1.0 X-Originating-IP: [46.139.80.5] In-Reply-To: References: <20140930191933.GC5011@tucsk.piliscsaba.szeredi.hu> <542BE551.1010705@parallels.com> <543F9E75.2090509@parallels.com> <20141017085509.GE5011@tucsk.piliscsaba.szeredi.hu> Date: Sat, 18 Oct 2014 20:01:13 +0200 Message-ID: Subject: Re: [PATCH 0/5] fuse: handle release synchronously (v4) From: Miklos Szeredi To: Linus Torvalds Cc: Maxim Patlasov , Anand Avati , Linux Kernel Mailing List , Michael j Theall , 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 On Sat, Oct 18, 2014 at 5:40 PM, Linus Torvalds wrote: > On Sat, Oct 18, 2014 at 8:35 AM, Linus Torvalds > wrote: >> >> Look around for AIO. Look around for the loop driver. Look around for >> a number of things that do "fget()" and that you completely ignored. > > .. actually, there are more instances of "get_file()" than of > "fget()", the aio one just happened to be the latter form. Lots and > lots of ways to get ahold of a file descriptor that keeps it open past > the "last close". And what you don't get is that there's a deep difference between those and the /proc file access case. And the difference is that one is done because of an explicit action by the holder of the open file. And the other is done by some random process doing non-invasive examination of the holder of the open-file. So basically: we simply don't care if last close does not happen to release the file *iff* it was because of some explicit action that obviously has or could have such a side effect. Is that so hard to understand? In other words, we care about doing that last release synchronously if it provably is the last release of that file and happens to be done from close() (or munmap()). And then all your examples of loop driver and aio are pointless, because we *know* they will be holding onto that descriptor, the same as we know, that after dup(), close() will not release the file and the (non-IDIOTIX) locks together with the file. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/