From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756606Ab2DTCb1 (ORCPT ); Thu, 19 Apr 2012 22:31:27 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:58691 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751460Ab2DTCbX convert rfc822-to-8bit (ORCPT ); Thu, 19 Apr 2012 22:31:23 -0400 MIME-Version: 1.0 In-Reply-To: <20120420004303.GB6871@ZenIV.linux.org.uk> References: <1334754302.2137.8.camel@falcor> <1334772473.2137.22.camel@falcor> <20120418183938.GH6589@ZenIV.linux.org.uk> <1334865448.2429.35.camel@falcor> <20120420004303.GB6871@ZenIV.linux.org.uk> From: Linus Torvalds Date: Thu, 19 Apr 2012 19:31:01 -0700 X-Google-Sender-Auth: O-dqhtfY9hjp96bmBsO6lKbzv_A Message-ID: Subject: Re: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches) To: Al Viro Cc: linux-fsdevel@vger.kernel.org, James Morris , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Safford , Dmitry Kasatkin , Mimi Zohar , David Miller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 19, 2012 at 5:43 PM, Al Viro wrote: > > However, there's an approach that might be feasible.  Most of the time > the final fput() *is* done without any locks held and there's a very > large subclass of those call sites - those that come via fput_light(). > What we could do, and what might be maintainable is: >        * prohibit fput_light() with locks held.  Right now we are very > close to that (or already there - I haven't finished checking). >        * convert low-hanging fget/fput in syscalls to fget_light/fput_light. > Makes sense anyway. Many of them would make sense, yes (looking at vfs_fstatat() etc. But a lot of fput() calls come from close() -> filp_close -> fput(). And the "fput_light()" model *only* works together with fget_light() as it is now. So I do think you need some other model. Of course, we can just do "fput_light(file, 1)" instead - that seems pretty ugly, though. But just making "fput()" do a defer on the last count sounds actively *wrong* for things like close(), which may actually have serious consistency guarantees (ie the process doing the close() may "know" that it is the last user, and depend on the fact that the close() did actually delete the inode etc. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches) Date: Thu, 19 Apr 2012 19:31:01 -0700 Message-ID: References: <1334754302.2137.8.camel@falcor> <1334772473.2137.22.camel@falcor> <20120418183938.GH6589@ZenIV.linux.org.uk> <1334865448.2429.35.camel@falcor> <20120420004303.GB6871@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org, James Morris , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Safford , Dmitry Kasatkin , Mimi Zohar , David Miller To: Al Viro Return-path: Received: from mail-wi0-f172.google.com ([209.85.212.172]:58691 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751460Ab2DTCbX convert rfc822-to-8bit (ORCPT ); Thu, 19 Apr 2012 22:31:23 -0400 In-Reply-To: <20120420004303.GB6871@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Apr 19, 2012 at 5:43 PM, Al Viro wrot= e: > > However, there's an approach that might be feasible. =A0Most of the t= ime > the final fput() *is* done without any locks held and there's a very > large subclass of those call sites - those that come via fput_light()= =2E > What we could do, and what might be maintainable is: > =A0 =A0 =A0 =A0* prohibit fput_light() with locks held. =A0Right now = we are very > close to that (or already there - I haven't finished checking). > =A0 =A0 =A0 =A0* convert low-hanging fget/fput in syscalls to fget_li= ght/fput_light. > Makes sense anyway. Many of them would make sense, yes (looking at vfs_fstatat() etc. But a lot of fput() calls come from close() -> filp_close -> fput(). And the "fput_light()" model *only* works together with fget_light() as it is now. So I do think you need some other model. Of course, we can just do "fput_light(file, 1)" instead - that seems pretty ugly, though. But just making "fput()" do a defer on the last count sounds actively *wrong* for things like close(), which may actually have serious consistency guarantees (ie the process doing the close() may "know" that it is the last user, and depend on the fact that the close() did actually delete the inode etc. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html