From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755604AbZBVBtw (ORCPT ); Sat, 21 Feb 2009 20:49:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753016AbZBVBtn (ORCPT ); Sat, 21 Feb 2009 20:49:43 -0500 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 Subject: Re: next-20090220: XFS, IMA: BUG: sleeping function called from invalid context at mm/slub.c:1613 From: Mimi Zohar 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 In-Reply-To: <20090220142807.a28734a8.akpm@linux-foundation.org> References: <20090220122242.b36a778f.akpm@linux-foundation.org> <1235168219.3019.4.camel@localhost.localdomain> <20090220142807.a28734a8.akpm@linux-foundation.org> Content-Type: text/plain Date: Sat, 21 Feb 2009 20:49:37 -0500 Message-Id: <1235267377.3441.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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