On Mon 26-12-16 17:11:29, Amir Goldstein wrote: > On Thu, Dec 22, 2016 at 11:15 AM, Jan Kara <jack@xxxxxxx> wrote: > > fanotify wants to drop fsnotify_mark_srcu lock when waiting for response > > from userspace so that the whole notification subsystem is not blocked > > during that time. This patch provides a framework for safely getting > > mark reference for a mark found in the object list which pins the mark > > in that list. We can then drop fsnotify_mark_srcu, wait for userspace > > response and then safely continue iteration of the object list once we > > reaquire fsnotify_mark_srcu. > > > > Signed-off-by: Jan Kara <jack@xxxxxxx> > > --- > ... > > + /* > > + * Now that both marks are pinned by refcount we can drop SRCU lock. > > + * Marks can still be removed from the list but because of refcount > > + * they cannot be destroyed and we can safely resume the list iteration > > + * once userspace returns. > > + */ > > Sorry, forgot to comment on this. > "Marks can still be removed from the list ... > ... and we can safely resume the list iteration" > > I suppose you are plannig to get the mechanics right, by replacing > hlist_del_init() with just __hlist_del() ?? but this sentence is confusing. > Usually, it wouldn't be safe to resume iteration if items may have been removed, > so perhaps rephrase or clarify. The point is that marks that have refcount elevated cannot be even removed from the list we iterate (that happens only once the last reference is dropped). That is the reason why we are safe to resume the iteration... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
