Re: [RFC PATCH -v4 07/14] fsnotify: add in inode fsnotify markings

[Eric Paris]

On Mon, 2008-12-22 at 13:43 +0000, Al Viro wrote:
> On Sat, Dec 13, 2008 at 11:35:09AM -0500, Eric Paris wrote:
> 
> > So to find an entry we need to first grab the inode->i_lock and start to
> > walk the inode->i_fsnotify_mark_entries list.  Since we hold the i_lock
> > we are not allowed to grab any other locks nor are we allowed to change
> > anything other than entry->i_list.  The secret sauce is that we actually
> > move the entry from the inode list to a private list which we can walk
> > and modify lockless.  Inside the event we actually have to use a
> > different list, free_i_list, for this operation so nothing else that
> > races with us can mess stuff up.  We run the entire inode we are trying
> > to free all entries for an put the entries on the private list.  We do
> > NOT modify event->inode.
> 
> And just what happens if #3 ("remove entry") hits us in the meanwhile?  Freed
> object sitting on free_i_list?

In the code on list, nothing.  Evgeniy Polyakov pointed out that I
grabbed my marks at the wrong time.

http://lkml.org/lkml/2008/12/13/94

The corrected idea is that while under the i_lock I call
fsnotify_get_mark() on every inode mark that I am moving to the
free_i_list.  When #3 races it actually does all of the cleanup,
including setting the "freeme" flag.  But it won't be able to get the
refcnt down to 0.  Once we finish 'cleaning up,' we call put on the
object and the refcnt will actually go to 0 and be freed.

The memory can't be freed as long as it is on a free_{i,g}_list.

-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/