From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761226Ab2D0SwM (ORCPT ); Fri, 27 Apr 2012 14:52:12 -0400 Received: from mga05.intel.com ([192.55.52.89]:48776 "EHLO fmsmga101.fm.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1760242Ab2D0SwK convert rfc822-to-8bit (ORCPT ); Fri, 27 Apr 2012 14:52:10 -0400 MIME-Version: 1.0 In-Reply-To: <20120427173417.GK6871@ZenIV.linux.org.uk> References: <1334865448.2429.35.camel@falcor> <20120420004303.GB6871@ZenIV.linux.org.uk> <20120420190418.GK6871@ZenIV.linux.org.uk> <20120420195833.GM6871@ZenIV.linux.org.uk> <20120420221315.GN6871@ZenIV.linux.org.uk> <20120427173417.GK6871@ZenIV.linux.org.uk> Date: Fri, 27 Apr 2012 21:52:09 +0300 Message-ID: Subject: Re: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches) From: "Kasatkin, Dmitry" To: Al Viro Cc: Linus Torvalds , Hugh Dickins , linux-fsdevel@vger.kernel.org, James Morris , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Safford , Mimi Zohar , David Miller , Andrew Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 27, 2012 at 8:34 PM, Al Viro wrote: > On Fri, Apr 27, 2012 at 10:35:25AM +0300, Kasatkin, Dmitry wrote: > >> But have you seen the proposed patch for __fput()? >> [PATCH v4 10/12] ima: defer calling __fput() >> >> It defers only of course the last AND mmap_sem is locked AND open for write. >> >>       if (current->mm && rwsem_is_locked(¤t->mm->mmap_sem)) { >>               if (ima_defer_fput(file) == 0) >>                       return; >>       } >> >> Just 5 out of ~100,000 mmap_sem held fput() calls were deferred. > > Let me get it straight. >        a) You still ignore all the problems with that described in the > posting right in the beginning of this thread. >        b) You ignore the problems with semantics changes from user-visible > delays of fput() past the return from syscall (described in Linus' posting > upthread - they apply to this "solution" as well). >        c) You seem to consider the fact that this path will be exercised > very rarely, thus making any races on it damn hard to reproduce and debug > as a good thing. > > And as for the sentiment expressed in the beginning of your posting (that > smaller patch size is worth more than clean locking rules, maintainability > of resulting kernel, etc.)...  I'm sorry, but you guys need to decide > what IMA is.  If it's a first-class part of the kernel, you have your > priorities backwards... Hello, I do not ignore anything. I said that we were thinking about solution to get the list of file to fput them after mmap unlock. And I do understand the issues discussed. I just wanted to know more opinions on proposed patch. - Dmitry From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kasatkin, Dmitry" Subject: Re: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches) Date: Fri, 27 Apr 2012 21:52:09 +0300 Message-ID: References: <1334865448.2429.35.camel@falcor> <20120420004303.GB6871@ZenIV.linux.org.uk> <20120420190418.GK6871@ZenIV.linux.org.uk> <20120420195833.GM6871@ZenIV.linux.org.uk> <20120420221315.GN6871@ZenIV.linux.org.uk> <20120427173417.GK6871@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Linus Torvalds , Hugh Dickins , linux-fsdevel@vger.kernel.org, James Morris , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Safford , Mimi Zohar , David Miller , Andrew Morton To: Al Viro Return-path: In-Reply-To: <20120427173417.GK6871@ZenIV.linux.org.uk> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Apr 27, 2012 at 8:34 PM, Al Viro wrot= e: > On Fri, Apr 27, 2012 at 10:35:25AM +0300, Kasatkin, Dmitry wrote: > >> But have you seen the proposed patch for __fput()? >> [PATCH v4 10/12] ima: defer calling __fput() >> >> It defers only of course the last AND mmap_sem is locked AND open fo= r write. >> >> =C2=A0 =C2=A0 =C2=A0 if (current->mm && rwsem_is_locked(¤t->mm= ->mmap_sem)) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ima_defer_fput(= file) =3D=3D 0) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 return; >> =C2=A0 =C2=A0 =C2=A0 } >> >> Just 5 out of ~100,000 mmap_sem held fput() calls were deferred. > > Let me get it straight. > =C2=A0 =C2=A0 =C2=A0 =C2=A0a) You still ignore all the problems with = that described in the > posting right in the beginning of this thread. > =C2=A0 =C2=A0 =C2=A0 =C2=A0b) You ignore the problems with semantics = changes from user-visible > delays of fput() past the return from syscall (described in Linus' po= sting > upthread - they apply to this "solution" as well). > =C2=A0 =C2=A0 =C2=A0 =C2=A0c) You seem to consider the fact that this= path will be exercised > very rarely, thus making any races on it damn hard to reproduce and d= ebug > as a good thing. > > And as for the sentiment expressed in the beginning of your posting (= that > smaller patch size is worth more than clean locking rules, maintainab= ility > of resulting kernel, etc.)... =C2=A0I'm sorry, but you guys need to d= ecide > what IMA is. =C2=A0If it's a first-class part of the kernel, you have= your > priorities backwards... Hello, I do not ignore anything. I said that we were thinking about solution to get the list of file to fput them after mmap unlock. And I do understand the issues discussed. I just wanted to know more opinions on proposed patch. - Dmitry -- 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