Re: [RFC][PATCH] (#7U5) [2-6.12-rc3-mm3] file system auditing
On Wednesday 11 May 2005 14:01, serue(a)us.ibm.com wrote:
Quoting Timothy R. Chavez (tinytim(a)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.
I think you'll need to reintroduce the audit_master_watchlist_lock
spinlock, and use only in audit_destroy_wentry().
This is based on a quick read, and I can't say I have a complete picture
of your structures right now, so I could be wrong... but conceptually I
don't see how you can protect the global list with an
inode->inode_data->rw_lock.
You can only remove a watch from the master watchlist at the same time you're
removing the watch from its local watchlist. Thus, if there is contention,
the lock is held, such that no other contender can enter
audit_destroy_wentry()
Mind you, this list does seem like an excellent RCU candidate, so it's a
good switch to make.
Yeah, I think I'm getting a better understanding of it... and I'm devicing in
my sleep, a way to remove the local reader-writer lock completely in place of
a global spinlock. Exciting huh? :)
-tim