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

[Serge Hallyn]

On Fri, 2005-03-18 at 14:51 -0600, Timothy R. Chavez wrote:

> > - 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)?
> 
> Originally, I just allocated space for each inode unconditionally, but was 
> told that this was unacceptable and that only inodes that require audit data, 
> should receive audit data.  In your opinion, what will the fsdevel guys be 
> most receptive too, lkml?  What would you do?  The added complexity does make 
> the entire thing a bit dodgy.  There's definately "more room for error". 
> 
> Can I get some feedback from Chris, Serge, and David?  I have no problem 
> reworking this, if we agree it needs to be reworked.

It looks like we could pare it down to

struct audit_data {
	struct audit_wentry *wentry;
	struct hlist_head *watchlist;
	rwlock_t watchlist_lock;
};

With spinlock debugging and preemption off, we're down to just three
longs per inode, so I guess it's not so bad.

Perhaps we could also use rcu to protect the watchlist, using the i_sem
to guard against racing writers?

-serge
-- 
Serge Hallyn <serue at us.ibm.com>