On Wed, Jan 4, 2017 at 11:03 AM, Jan Kara <jack@xxxxxxx> wrote: > 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... > Well, if they "cannot be even removed" then the comment above that says "Marks can still be removed... but cannot be destroyed" is inaccurate or at the very least confusing. Amir. -- 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
