[RFC][PATCH] (#7U5) [2-6.12-rc3-mm3] file system auditing

[serue at us.ibm.com]

Quoting Timothy R. Chavez (tinytim at us.ibm.com):
> On Wednesday 11 May 2005 14:01, serue at us.ibm.com wrote:
> > Quoting Timothy R. Chavez (tinytim at us.ibm.com):
> > > * I've completely removed the audit_master_watchlist_lock spinlock to
> > > protect the master watchlist, in favor of RCU locking. ?To protect
> > > against concurrent watch removals from the master watchlist, we
> > > conveniently use the local data->lock rw_lock in place of another
> > > spinlock. ?Thus, only one removal can
> >
> > I have a problem with this.  Isn't the audit_master_watchlist a global
> > list?  Are you sure you can use a per-inode lock to protect this global
> > list?
> 
> Well, my conclusion was this:  The only way to enter audit_destroy_wentry() 
> where contention is a concern is by holding the local data->lock.  The only 
> way we can remove a watch from the master watchlist is by entering the 
> audit_destroy_wentry() function (and if contentious, only one of the 
> contenders may be in audit_destroy_wentry() at a time).
> 
> I don't see how we could race on a master watchlist deletion.

1. What if you end up trying to delete two wentries which are adjecent
on the audit_master_watchlist concurrently?  I think you might be able
to break the list, but I haven't drawn it down on paper...

2. What about additions to the audit_master_watchlist, both racing with
each other and with deletions?  Actually it doesn't look like you're
protecting additions at all.

-serge