From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Lino Sanfilippo <LinoSanfilippo@gmx.de>,
Miklos Szeredi <miklos@szeredi.hu>,
Paul Moore <paul@paul-moore.com>
Subject: Re: [PATCH 13/22] fsnotify: Provide framework for dropping SRCU lock in ->handle_event
Date: Wed, 4 Jan 2017 12:45:51 +0100 [thread overview]
Message-ID: <20170104114551.GP3780@quack2.suse.cz> (raw)
In-Reply-To: <CAOQ4uxiU2TnvowYLeYxpGWUaEze1c7_-CTMvA0auBMRBhgNxmQ@mail.gmail.com>
On Wed 04-01-17 12:50:48, Amir Goldstein wrote:
> On Wed, Jan 4, 2017 at 11:03 AM, Jan Kara <jack@suse.cz> wrote:
> > On Mon 26-12-16 17:11:29, Amir Goldstein wrote:
> >> On Thu, Dec 22, 2016 at 11:15 AM, Jan Kara <jack@suse.cz> 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@suse.cz>
> >> > ---
> >> ...
> >> > + /*
> >> > + * 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.
Good spotting. The comment is just wrong (it used to be like that in
previous version of the patch set but not anymore). I'll fix it.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2017-01-04 11:46 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-22 9:15 [PATCH 0/22] fsnotify: Avoid SRCU stalls with fanotify permission events Jan Kara
2016-12-22 9:15 ` [PATCH 01/22] fsnotify: Remove unnecessary tests when showing fdinfo Jan Kara
2016-12-22 12:59 ` Amir Goldstein
2016-12-22 15:16 ` Jan Kara
2016-12-22 15:54 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 02/22] inotify: Remove inode pointers from debug messages Jan Kara
2016-12-22 15:31 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 03/22] fanotify: Move recalculation of inode / vfsmount mask under mark_mutex Jan Kara
2016-12-22 16:27 ` Amir Goldstein
2016-12-22 17:31 ` Jan Kara
2016-12-22 19:08 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 04/22] fsnotify: Remove fsnotify_duplicate_mark() Jan Kara
2016-12-22 23:13 ` Paul Moore
2016-12-23 13:22 ` Jan Kara
2016-12-23 14:01 ` Paul Moore
2016-12-22 9:15 ` [PATCH 05/22] audit: Fix sleep in atomic Jan Kara
2016-12-22 23:18 ` Paul Moore
2016-12-23 13:24 ` Jan Kara
2016-12-23 14:17 ` Paul Moore
2016-12-26 16:33 ` Paul Moore
2017-01-02 18:21 ` Jan Kara
2017-01-03 21:11 ` Paul Moore
2017-01-04 8:50 ` Jan Kara
2017-01-05 2:14 ` Paul Moore
2016-12-22 9:15 ` [PATCH 06/22] audit: Abstract hash key handling Jan Kara
2016-12-22 23:27 ` Paul Moore
2016-12-23 13:27 ` Jan Kara
2016-12-23 14:13 ` Paul Moore
2017-01-03 17:34 ` Jan Kara
2017-01-05 2:06 ` Paul Moore
2016-12-22 9:15 ` [PATCH 07/22] fsnotify: Update comments Jan Kara
2016-12-23 4:45 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 08/22] fsnotify: Attach marks to object via dedicated head structure Jan Kara
2016-12-23 5:48 ` Amir Goldstein
2016-12-23 13:34 ` Jan Kara
2017-01-04 13:38 ` Jan Kara
2017-01-04 15:29 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 09/22] inotify: Do not drop mark reference under idr_lock Jan Kara
2016-12-23 8:04 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 10/22] fsnotify: Detach mark from object list when last reference is dropped Jan Kara
2016-12-23 10:51 ` Amir Goldstein
2016-12-23 13:42 ` Jan Kara
2016-12-22 9:15 ` [PATCH 11/22] fsnotify: Remove special handling of mark destruction on group shutdown Jan Kara
2016-12-23 12:12 ` Amir Goldstein
2016-12-23 13:31 ` Jan Kara
2016-12-22 9:15 ` [PATCH 12/22] fsnotify: Move queueing of mark for destruction into fsnotify_put_mark() Jan Kara
2016-12-26 14:15 ` Amir Goldstein
2017-01-04 10:28 ` Jan Kara
2017-01-04 12:22 ` Jan Kara
2016-12-22 9:15 ` [PATCH 13/22] fsnotify: Provide framework for dropping SRCU lock in ->handle_event Jan Kara
2016-12-26 15:01 ` Amir Goldstein
2016-12-26 15:11 ` Amir Goldstein
2017-01-04 9:03 ` Jan Kara
2017-01-04 10:50 ` Amir Goldstein
2017-01-04 11:45 ` Jan Kara [this message]
2016-12-26 18:37 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 14/22] fsnotify: Pass SRCU index into handle_event handler Jan Kara
2016-12-26 15:13 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 15/22] fanotify: Release SRCU lock when waiting for userspace response Jan Kara
2016-12-26 15:22 ` Amir Goldstein
2017-01-04 9:05 ` Jan Kara
2016-12-22 9:15 ` [PATCH 16/22] fsnotify: Remove fsnotify_set_mark_{,ignored_}mask_locked() Jan Kara
2016-12-26 16:42 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 17/22] fsnotify: Remove fsnotify_recalc_{inode|vfsmount}_mask() Jan Kara
2016-12-26 16:44 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 18/22] fsnotify: Inline fsnotify_clear_{inode|vfsmount|_mark_group() Jan Kara
2016-12-26 16:57 ` Amir Goldstein
2017-01-04 9:28 ` Jan Kara
2016-12-22 9:15 ` [PATCH 19/22] fsnotify: Remove fsnotify_find_{inode|vfsmount}_mark() Jan Kara
2016-12-26 17:14 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 20/22] fsnotify: Drop inode_mark.c Jan Kara
2016-12-26 17:15 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 21/22] fsnotify: Add group pointer in fsnotify_init_mark() Jan Kara
2016-12-26 17:34 ` Amir Goldstein
2016-12-22 9:15 ` [PATCH 22/22] fsnotify: Move ->free_mark callback to fsnotify_ops Jan Kara
2016-12-26 17:39 ` Amir Goldstein
2016-12-22 20:58 ` [PATCH 0/22] fsnotify: Avoid SRCU stalls with fanotify permission events Paul Moore
2016-12-22 21:05 ` Amir Goldstein
2016-12-22 23:04 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170104114551.GP3780@quack2.suse.cz \
--to=jack@suse.cz \
--cc=LinoSanfilippo@gmx.de \
--cc=amir73il@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).