Re: [RFC][PATCH] (#6) filesystem auditing
On Fri, 2005-03-18 at 14:51 -0600, Timothy R. Chavez wrote:
The audit_data stack really doesn't need protection because
theoretically pushing/popping to it, by virtue of the locking and where they
are placed, this should be done linearly.
The latter (where they are placed) is what concerns me, if you are
relying on dcache_lock being held by the caller to guarantee
serialization. IMHO, you shouldn't rely on an unrelated lock held by
the caller to protect your own data structures; think about what happens
when someday down the road, someone changes the calling code to not
require the dcache lock anymore.
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".
I'm only talking about allocating the structure that is hung off of
i_audit, not necessarily generating any audit data for it. This is
consistent with the current handling of task audit contexts (where we
always allocate in advance unless explicitly marked as having audit
disabled) and paths (where we always collect components as we don't know
in advance whether it will require audit). So I think pre-allocating
that initial audit structure for the inode upon audit_alloc_inode is
quite reasonable, and necessary for sane processing later.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency