From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932375Ab2DTC7V (ORCPT ); Thu, 19 Apr 2012 22:59:21 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:59032 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932106Ab2DTC7T convert rfc822-to-8bit (ORCPT ); Thu, 19 Apr 2012 22:59:19 -0400 MIME-Version: 1.0 In-Reply-To: <20120420025438.GD6871@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> <20120420025438.GD6871@ZenIV.linux.org.uk> From: Linus Torvalds Date: Thu, 19 Apr 2012 19:58:57 -0700 X-Google-Sender-Auth: PIkrCWgG7UASxy9z-4CIy9UiCes 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 7:54 PM, Al Viro wrote: > > Umm...  I really wonder if we *want* filp_close() under any kind of > locks.  You are right - it should not be deferred.  I haven't finished > checking the callers of that puppy, but if we really do it while holding > any kind of lock, we are asking for trouble.  So I'd rather switch > filp_close() to use of fput_nodefer() if that turns out to be possible. Ok, fair enough, looks like a reasonable plan to me. 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:58:57 -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> <20120420025438.GD6871@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: In-Reply-To: <20120420025438.GD6871@ZenIV.linux.org.uk> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Apr 19, 2012 at 7:54 PM, Al Viro wrot= e: > > Umm... =A0I really wonder if we *want* filp_close() under any kind of > locks. =A0You are right - it should not be deferred. =A0I haven't fin= ished > checking the callers of that puppy, but if we really do it while hold= ing > any kind of lock, we are asking for trouble. =A0So I'd rather switch > filp_close() to use of fput_nodefer() if that turns out to be possibl= e. Ok, fair enough, looks like a reasonable plan to me. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-securit= y-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html