From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mimi Zohar Subject: Re: next-20090220: XFS, IMA: BUG: sleeping function called from invalid context at mm/slub.c:1613 Date: Sat, 21 Feb 2009 20:49:37 -0500 Message-ID: <1235267377.3441.24.camel@localhost.localdomain> References: <20090220122242.b36a778f.akpm@linux-foundation.org> <1235168219.3019.4.camel@localhost.localdomain> <20090220142807.a28734a8.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from e36.co.us.ibm.com ([32.97.110.154]:47968 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752842AbZBVBtm (ORCPT ); Sat, 21 Feb 2009 20:49:42 -0500 In-Reply-To: <20090220142807.a28734a8.akpm@linux-foundation.org> Sender: linux-next-owner@vger.kernel.org List-ID: To: Andrew Morton Cc: a.beregalov@gmail.com, linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, xfs@oss.sgi.com, jmorris@namei.org, david safford On Fri, 2009-02-20 at 14:28 -0800, Andrew Morton wrote: > On Fri, 20 Feb 2009 17:16:59 -0500 > Mimi Zohar wrote: > > > integrity: ima iint radix_tree_lookup locking fix > > > > Based on Andrew Morton's comments: > > - add missing locks around radix_tree_lookup in ima_iint_insert() > > > > Signed-off-by: Mimi Zohar > > > > Index: security-testing-2.6/security/integrity/ima/ima_iint.c > > =================================================================== > > --- security-testing-2.6.orig/security/integrity/ima/ima_iint.c > > +++ security-testing-2.6/security/integrity/ima/ima_iint.c > > @@ -73,8 +73,10 @@ out: > > if (rc < 0) { > > kmem_cache_free(iint_cache, iint); > > if (rc == -EEXIST) { > > + spin_lock(&ima_iint_lock); > > iint = radix_tree_lookup(&ima_iint_store, > > (unsigned long)inode); > > + spin_unlock(&ima_iint_lock); > > } else > > iint = NULL; > > } > > Can the -EEXIST ever actually happen? > On the inode_init_always() path (at least), I don't think that any > other thread of control can have access to this inode*, so there is no > way in which a race can result in someone else adding this inode > first? True, but for those inodes which were allocated before IMA was enabled and are being allocated in ima_iint_find_insert_get(), it could be an issue. > Also, idle question: why does the radix tree exist at all? Would it > have been possible to just add a `struct ima_iint_cache *' field to the > inode instead? Up until November the iint was defined directly in the inode. This changed based on Christoph Hellwig's posting http://lkml.org/lkml/2008/10/14/170 where he said, "bloating the inode for this is not an option". Mimi Zohar