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

[Timothy R. Chavez]

On Wednesday 11 May 2005 14:51, serue at us.ibm.com wrote:
> 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...

Hm.  Yeah, sounds like in this case, it'll break.  I'll have to think about 
this scenario a bit more.

>
> 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.
>

There won't be racing insertions.  The audit_netlink_sem ensures us that there 
will only ever be one insertion at a time and while we're inserting.  Also, 
if we are inserting, we can't explicitly be removing.  The only way to delete 
is from audit_update_watch().  So conceptually, I suppose, if we're in the 
process of draining the watchlist and we're attempting to insert into that 
watchlist at the same time, there might be some ill effect?  I suppose it 
doesn't hurt to keep the locking here for this case.

> -serge
>
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit

-- 
-tim