All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org,
	Miklos Szeredi <mszeredi@redhat.com>,
	Lino Sanfilippo <LinoSanfilippo@gmx.de>,
	Eric Paris <eparis@redhat.com>, Al Viro <viro@ZenIV.linux.org.uk>,
	Jan Kara <jack@suse.cz>
Subject: [PATCH 3/6] fsnotify: Drop notification_mutex before destroying event
Date: Tue, 13 Sep 2016 22:15:08 +0200	[thread overview]
Message-ID: <1473797711-14111-4-git-send-email-jack@suse.cz> (raw)
In-Reply-To: <1473797711-14111-1-git-send-email-jack@suse.cz>

fsnotify_flush_notify() and fanotify_release() destroy notification
event while holding notification_mutex. Destruction of fanotify event
includes a path_put() call which may end up calling into a filesystem to
delete an inode if we happen to be the last holders of dentry reference
which happens to be the last holder of inode reference. That may violate
lock ordering for some filesystems since notification_mutex is also
acquired e. g. during write when generating fanotify event. Also this is
the only thing that forces notification_mutex to be a sleeping lock.  So
drop notification_mutex before destroying a notification event.

Signed-off-by: Jan Kara <jack@suse.cz>
---
 fs/notify/fanotify/fanotify_user.c | 6 ++++--
 fs/notify/notification.c           | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index a64313868d3a..46d135c4988f 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -390,9 +390,11 @@ static int fanotify_release(struct inode *ignored, struct file *file)
 	mutex_lock(&group->notification_mutex);
 	while (!fsnotify_notify_queue_is_empty(group)) {
 		fsn_event = fsnotify_remove_first_event(group);
-		if (!(fsn_event->mask & FAN_ALL_PERM_EVENTS))
+		if (!(fsn_event->mask & FAN_ALL_PERM_EVENTS)) {
+			mutex_unlock(&group->notification_mutex);
 			fsnotify_destroy_event(group, fsn_event);
-		else
+			mutex_lock(&group->notification_mutex);
+		} else
 			FANOTIFY_PE(fsn_event)->response = FAN_ALLOW;
 	}
 	mutex_unlock(&group->notification_mutex);
diff --git a/fs/notify/notification.c b/fs/notify/notification.c
index e455e83ceeeb..7d563dea52a4 100644
--- a/fs/notify/notification.c
+++ b/fs/notify/notification.c
@@ -178,7 +178,9 @@ void fsnotify_flush_notify(struct fsnotify_group *group)
 	mutex_lock(&group->notification_mutex);
 	while (!fsnotify_notify_queue_is_empty(group)) {
 		event = fsnotify_remove_first_event(group);
+		mutex_unlock(&group->notification_mutex);
 		fsnotify_destroy_event(group, event);
+		mutex_lock(&group->notification_mutex);
 	}
 	mutex_unlock(&group->notification_mutex);
 }
-- 
2.6.6


  parent reply	other threads:[~2016-09-13 20:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-13 20:15 [PATCH 0/6 v2] fsnotify: Fix list corruption for permission events Jan Kara
2016-09-13 20:15 ` [PATCH 1/6] fsnotify: Add a way to stop queueing events on group shutdown Jan Kara
2016-09-13 20:15 ` [PATCH 2/6] fanotify: Fix list corruption in fanotify_get_response() Jan Kara
2016-09-13 20:15 ` Jan Kara [this message]
2016-09-14 17:11   ` [PATCH 3/6] fsnotify: Drop notification_mutex before destroying event Lino Sanfilippo
2016-09-13 20:15 ` [PATCH 4/6] fsnotify: Convert notification_mutex to a spinlock Jan Kara
2016-09-14 17:13   ` Lino Sanfilippo
2016-09-13 20:15 ` [PATCH 5/6] fanotify: Use notification_lock instead of access_lock Jan Kara
2016-09-14 17:14   ` Lino Sanfilippo
2016-09-13 20:15 ` [PATCH 6/6] fanotify: Fix possible false warning when freeing events Jan Kara
2016-09-14 17:14   ` Lino Sanfilippo

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=1473797711-14111-4-git-send-email-jack@suse.cz \
    --to=jack@suse.cz \
    --cc=LinoSanfilippo@gmx.de \
    --cc=akpm@linux-foundation.org \
    --cc=eparis@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=viro@ZenIV.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.