Re: [RFC][PATCH] (#6) filesystem auditing
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(a)us.ibm.com>