[RFC][PATCH] (#6) filesystem auditing

[Stephen Smalley]

On Mon, 2005-03-14 at 17:14 -0600, Timothy R. Chavez wrote:
> The only thing I'm a little concerned about in this patch has to do with 
> audit_watch_insert().  I think I need to lock around where I check to see if 
> the watchlist is empty and then possibly update the inode.  Other then that,  
> I think I have it pretty much all covered.  I feel more comfortable with the 
> locking in patch #6 then I did in patch #5. 

- Is there any reason to use the irqsave/irqrestore form of the locks?
When is your code ever called from irq?

- Relying on locking in the caller to protect your own data structures
seems fragile and unmaintainable; I don't think you want to rely on the
caller holding dentry->d_lock for exclusion for your own lists, e.g. the
audit data stack?

- I'm a bit concerned by the whole audit data stack model; sorry to
bring it up now.  Is the resulting complexity truly justified (vs. up
front allocations upon audit_inode_alloc, at the cost of wasting that
memory for inodes that never require watches, or an explicit hook
elsewhere at a point where we can perform blocking allocation and
propagate errors)?
 
-- 
Stephen Smalley <sds at tycho.nsa.gov>
National Security Agency