From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: [PATCH] audit: file system auditing based on location and name Date: Thu, 07 Jul 2005 07:50:01 +0100 Message-ID: <1120719001.8058.162.camel@baythorne.infradead.org> References: <1120668881.8328.1.camel@localhost> <1120718414.3198.11.camel@laptopd505.fenrus.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "Timothy R. Chavez" , Andrew Morton , linux-audit@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Mounir Bsaibes , Steve Grubb , Serge Hallyn , Alexander Viro , Klaus Weidner , Chris Wright , Stephen Smalley , Robert Love , Christoph Hellwig , Daniel H Jones , Amy Griffis , Maneesh Soni Return-path: To: Arjan van de Ven In-Reply-To: <1120718414.3198.11.camel@laptopd505.fenrus.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-07-07 at 08:40 +0200, Arjan van de Ven wrote: > why is this? It would be a very logical thing to store this stuff inside > the inode. It sounds like a bad design to keep per inode data out of the > inode. (if you're concerned about taking a lot of space, put a pointer > to a kmalloc()'d piece of memory into the inode instead). A hash is > just, well, odd for this. There are _very_ few of these; it's very dubious whether it'd be worth bloating the inode for them. The use of I_AUDIT also serves to pin the inode in icache, and we'd need something like that even if we _weren't_ using it as a marker for the hash table. -- dwmw2