From: Jan Kara <jack@suse.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.com>
Subject: [PATCH 3/3] fsnotify: Make fsnotify_destroy_mark_locked() safe without refcount
Date: Wed, 15 Jul 2015 15:21:21 +0200 [thread overview]
Message-ID: <1436966481-12517-4-git-send-email-jack@suse.com> (raw)
In-Reply-To: <1436966481-12517-1-git-send-email-jack@suse.com>
fsnotify_destroy_mark_locked() is almost safe without holding a
reference to destroyed mark (the comment before that function is
obviously stale as fsnotify_put_mark() isn't called in that function at
all). The only thing that may race with mark freeing is update of group
mark count so do that before queueing destruction of the mark. Also
update the comment to better describe reality.
With this change fsnotify_clear_marks_by_group_flags() has no need to grab
reference to fsnotify mark so just remove that.
Signed-off-by: Jan Kara <jack@suse.com>
---
fs/notify/mark.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/fs/notify/mark.c b/fs/notify/mark.c
index 3e594ce41010..f261bb4f7e47 100644
--- a/fs/notify/mark.c
+++ b/fs/notify/mark.c
@@ -122,9 +122,12 @@ u32 fsnotify_recalc_mask(struct hlist_head *head)
}
/*
- * Any time a mark is getting freed we end up here.
- * The caller had better be holding a reference to this mark so we don't actually
- * do the final put under the mark->lock
+ * Any time a mark is getting freed we end up here. We remove mark from
+ * inode / vfsmount list so that it cannot be found by new events, from the
+ * group list so that functions manipulating group cannot touch it, and queue
+ * it for further processing by notification kthread. We are still holding
+ * initial mark reference which gets dropped by the notification kthread once
+ * it's done destroying the mark.
*/
void fsnotify_destroy_mark_locked(struct fsnotify_mark *mark,
struct fsnotify_group *group)
@@ -157,11 +160,6 @@ void fsnotify_destroy_mark_locked(struct fsnotify_mark *mark,
if (inode && (mark->flags & FSNOTIFY_MARK_FLAG_OBJECT_PINNED))
iput(inode);
- spin_lock(&destroy_lock);
- list_add(&mark->g_list, &destroy_list);
- spin_unlock(&destroy_lock);
- wake_up(&destroy_waitq);
-
/*
* __fsnotify_update_child_dentry_flags(inode);
*
@@ -173,8 +171,13 @@ void fsnotify_destroy_mark_locked(struct fsnotify_mark *mark,
* children and will update all of these flags then. So really this
* is just a lazy update (and could be a perf win...)
*/
-
atomic_dec(&group->num_marks);
+
+ /* Queue for further destruction by kthread */
+ spin_lock(&destroy_lock);
+ list_add(&mark->g_list, &destroy_list);
+ spin_unlock(&destroy_lock);
+ wake_up(&destroy_waitq);
}
void fsnotify_destroy_mark(struct fsnotify_mark *mark,
@@ -400,11 +403,8 @@ void fsnotify_clear_marks_by_group_flags(struct fsnotify_group *group,
mutex_lock_nested(&group->mark_mutex, SINGLE_DEPTH_NESTING);
list_for_each_entry_safe(mark, lmark, &group->marks_list, g_list) {
- if (mark->flags & flags) {
- fsnotify_get_mark(mark);
+ if (mark->flags & flags)
fsnotify_destroy_mark_locked(mark, group);
- fsnotify_put_mark(mark);
- }
}
mutex_unlock(&group->mark_mutex);
}
--
2.1.4
prev parent reply other threads:[~2015-07-15 13:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-15 13:21 [PATCH 0/3] fsnotify: Cleanups and fixes Jan Kara
2015-07-15 13:21 ` [PATCH 1/3] fsnotify: Fix oops in fsnotify_clear_marks_by_group_flags() Jan Kara
2015-07-15 20:41 ` Andrew Morton
2015-07-16 6:50 ` Jan Kara
2015-07-19 10:21 ` Kinglong Mee
2015-07-20 14:46 ` Jan Kara
2015-07-21 20:03 ` Jan Kara
2015-07-21 20:35 ` Jan Kara
2015-07-21 23:14 ` Linus Torvalds
2015-07-22 0:26 ` Greg Kroah-Hartman
2015-07-21 20:36 ` Jan Kara
2015-07-20 15:24 ` Konstantin Khlebnikov
2015-07-15 13:21 ` [PATCH 2/3] fsnotify: Fix check in inotify fdinfo printing Jan Kara
2015-07-15 13:21 ` Jan Kara [this message]
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=1436966481-12517-4-git-send-email-jack@suse.com \
--to=jack@suse.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
/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).