X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id pB6Jo7Ns256832 for ; Tue, 6 Dec 2011 13:50:08 -0600 X-ASG-Debug-ID: 1323201005-4dbc02320000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e6.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 71DDC29F9CC for ; Tue, 6 Dec 2011 11:50:05 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by cuda.sgi.com with ESMTP id Nb4qZQrf91OUBCx6 for ; Tue, 06 Dec 2011 11:50:05 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 6 Dec 2011 14:50:04 -0500 Received: from d01relay03.pok.ibm.com (9.56.227.235) by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 6 Dec 2011 14:48:38 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB6Jmb77294236 for ; Tue, 6 Dec 2011 14:48:37 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pB6JmZTu014539 for ; Tue, 6 Dec 2011 14:48:36 -0500 Received: from [9.2.18.167] (dhcp-9-2-18-167.watson.ibm.com [9.2.18.167]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pB6JmZC1014523; Tue, 6 Dec 2011 14:48:35 -0500 X-ASG-Orig-Subj: Re: [PATCH] security: Delay freeing inode->i_security till the end of RCU grace period Subject: Re: [PATCH] security: Delay freeing inode->i_security till the end of RCU grace period From: Mimi Zohar To: sekharan@us.ibm.com Cc: Christoph Hellwig , sekharan@linux.vnet.ibm.com, linux-security-module@vger.kernel.org, Eric Paris , XFS Mailing List Date: Tue, 06 Dec 2011 14:45:53 -0500 In-Reply-To: <1323191093.31919.1475.camel@chandra-lucid.austin.ibm.com> References: <1323110541.31919.1451.camel@chandra-lucid.austin.ibm.com> <20111206151429.GB11874@infradead.org> <1323189102.2165.39.camel@falcor> <1323191093.31919.1475.camel@chandra-lucid.austin.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1323200753.2165.69.camel@falcor> Mime-Version: 1.0 x-cbid: 11120619-1976-0000-0000-0000084EEB18 X-Barracuda-Connect: e6.ny.us.ibm.com[32.97.182.146] X-Barracuda-Start-Time: 1323201006 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, 2011-12-06 at 11:04 -0600, Chandra Seetharaman wrote: > On Tue, 2011-12-06 at 11:30 -0500, Mimi Zohar wrote: > > On Tue, 2011-12-06 at 10:14 -0500, Christoph Hellwig wrote: > > > On Mon, Dec 05, 2011 at 12:42:21PM -0600, Chandra Seetharaman wrote: > > > > while running test case 234 from xfstests test suite, I was getting an > > > > occational memory fault in inode_has_perm() with the following stack > > > > > > Interesting. Given that have no good way to free other data with the > > > normal inode callback it looks like we indeed need to do this > > > separately. > > > > > > What about IMA or similar monsters? Posix ACLs already are covered at > > > least. > > > > Looks like a similar problem exists with the 'iint'. > > I walked thru the code and saw integrity_iint_find() is the one that > would be used to see if a iint data structure is associated. And, all > all the invocations of integrity_iint_find() check for NULL and handle > it properly. > > I might be wrong since I am not familiar with the code. Can you please > double check and let me know if I am wrong. > > Chandra The assumption up to this point has been that the iint will be freed only after the last call to ima_file_free(). The lack of an iint's existence indicates that the file is not in the measurement policy. As the iint is being freed, updating the iint flag is unnecessary for base IMA. However, in addition to updating the iint flags, the IMA-appraisal patches (yet to be upstreamed) update the 'security.ima' xattr. Without an iint, the xattr will not be updated. Mimi