From: Eric Paris <eparis@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: viro@zeniv.linux.org.uk, hch@infradead.org,
alan@lxorguk.ukuu.org.uk, sfr@canb.auug.org.au,
john@johnmccutchan.com, rlove@rlove.org,
akpm@linux-foundation.org
Subject: [PATCH -V2 12/13] fsnotify: handle filesystem unmounts with fsnotify marks
Date: Fri, 27 Mar 2009 16:06:11 -0400 [thread overview]
Message-ID: <20090327200611.32007.38991.stgit@paris.rdu.redhat.com> (raw)
In-Reply-To: <20090327200508.32007.63278.stgit@paris.rdu.redhat.com>
When an fs is unmounted with an fsnotify mark entry attached to one of its
inodes we need to destroy that mark entry and we also (like inotify) send
an unmount event.
Signed-off-by: Eric Paris <eparis@redhat.com>
---
fs/inode.c | 1 +
fs/notify/inode_mark.c | 73 ++++++++++++++++++++++++++++++++++++++
include/linux/fsnotify_backend.h | 4 ++
3 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 6a9a98e..7922d0b 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -406,6 +406,7 @@ int invalidate_inodes(struct super_block * sb)
mutex_lock(&iprune_mutex);
spin_lock(&inode_lock);
inotify_unmount_inodes(&sb->s_inodes);
+ fsnotify_unmount_inodes(&sb->s_inodes);
busy = invalidate_list(&sb->s_inodes, &throw_away);
spin_unlock(&inode_lock);
diff --git a/fs/notify/inode_mark.c b/fs/notify/inode_mark.c
index e9e89d2..06a00be 100644
--- a/fs/notify/inode_mark.c
+++ b/fs/notify/inode_mark.c
@@ -23,6 +23,7 @@
#include <linux/mutex.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
+#include <linux/writeback.h> /* for inode_lock */
#include <asm/atomic.h>
@@ -282,3 +283,75 @@ int fsnotify_add_mark(struct fsnotify_mark_entry *entry, struct fsnotify_group *
return ret;
}
+
+/**
+ * fsnotify_unmount_inodes - an sb is unmounting. handle any watched inodes.
+ * @list: list of inodes being unmounted (sb->s_inodes)
+ *
+ * Called with inode_lock held, protecting the unmounting super block's list
+ * of inodes, and with iprune_mutex held, keeping shrink_icache_memory() at bay.
+ * We temporarily drop inode_lock, however, and CAN block.
+ */
+void fsnotify_unmount_inodes(struct list_head *list)
+{
+ struct inode *inode, *next_i, *need_iput = NULL;
+
+ list_for_each_entry_safe(inode, next_i, list, i_sb_list) {
+ struct inode *need_iput_tmp;
+
+ /*
+ * If i_count is zero, the inode cannot have any watches and
+ * doing an __iget/iput with MS_ACTIVE clear would actually
+ * evict all inodes with zero i_count from icache which is
+ * unnecessarily violent and may in fact be illegal to do.
+ */
+ if (!atomic_read(&inode->i_count))
+ continue;
+
+ /*
+ * We cannot __iget() an inode in state I_CLEAR, I_FREEING, or
+ * I_WILL_FREE which is fine because by that point the inode
+ * cannot have any associated watches.
+ */
+ if (inode->i_state & (I_CLEAR | I_FREEING | I_WILL_FREE))
+ continue;
+
+ need_iput_tmp = need_iput;
+ need_iput = NULL;
+
+ /* In case fsnotify_inode_delete() drops a reference. */
+ if (inode != need_iput_tmp)
+ __iget(inode);
+ else
+ need_iput_tmp = NULL;
+
+ /* In case the dropping of a reference would nuke next_i. */
+ if ((&next_i->i_sb_list != list) &&
+ atomic_read(&next_i->i_count) &&
+ !(next_i->i_state & (I_CLEAR | I_FREEING | I_WILL_FREE))) {
+ __iget(next_i);
+ need_iput = next_i;
+ }
+
+ /*
+ * We can safely drop inode_lock here because we hold
+ * references on both inode and next_i. Also no new inodes
+ * will be added since the umount has begun. Finally,
+ * iprune_mutex keeps shrink_icache_memory() away.
+ */
+ spin_unlock(&inode_lock);
+
+ if (need_iput_tmp)
+ iput(need_iput_tmp);
+
+ /* for each watch, send FS_UNMOUNT and then remove it */
+ fsnotify(inode, FS_UNMOUNT, inode, FSNOTIFY_EVENT_INODE, NULL, 0);
+
+ fsnotify_inode_delete(inode);
+
+ iput(inode);
+
+ spin_lock(&inode_lock);
+ }
+}
+EXPORT_SYMBOL_GPL(fsnotify_unmount_inodes);
diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
index 2da9790..f2daf59 100644
--- a/include/linux/fsnotify_backend.h
+++ b/include/linux/fsnotify_backend.h
@@ -268,6 +268,7 @@ extern void fsnotify_destroy_mark_by_entry(struct fsnotify_mark_entry *entry);
extern void fsnotify_clear_marks_by_group(struct fsnotify_group *group);
extern void fsnotify_get_mark(struct fsnotify_mark_entry *entry);
extern void fsnotify_put_mark(struct fsnotify_mark_entry *entry);
+extern void fsnotify_unmount_inodes(struct list_head *list);
/* put here because inotify does some weird stuff when destroying watches */
extern struct fsnotify_event *fsnotify_create_event(struct inode *to_tell, __u32 mask, void *data,
@@ -290,6 +291,9 @@ static inline u32 fsnotify_get_cookie(void)
return 0;
}
+static inline void fsnotify_unmount_inodes(struct list_head *list)
+{}
+
#endif /* CONFIG_FSNOTIFY */
#endif /* __KERNEL __ */
next prev parent reply other threads:[~2009-03-27 20:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-27 20:05 [PATCH -V2 01/13] mutex: add atomic_dec_and_mutex_lock Eric Paris
2009-03-27 20:05 ` [PATCH -V2 02/13] fsnotify: unified filesystem notification backend Eric Paris
2009-04-07 23:05 ` Andrew Morton
2009-04-08 0:37 ` Eric Paris
2009-04-07 23:06 ` Andrew Morton
2009-03-27 20:05 ` [PATCH -V2 03/13] fsnotify: add group priorities Eric Paris
2009-04-07 23:06 ` Andrew Morton
2009-03-27 20:05 ` [PATCH -V2 04/13] fsnotify: add in inode fsnotify markings Eric Paris
2009-04-07 23:06 ` Andrew Morton
2009-03-27 20:05 ` [PATCH -V2 05/13] fsnotify: parent event notification Eric Paris
2009-04-07 23:06 ` Andrew Morton
2009-03-27 20:05 ` [PATCH -V2 06/13] dnotify: reimplement dnotify using fsnotify Eric Paris
2009-04-07 23:06 ` Andrew Morton
2009-03-27 20:05 ` [PATCH -V2 07/13] fsnotify: generic notification queue and waitq Eric Paris
2009-04-07 23:06 ` Andrew Morton
2009-03-27 20:05 ` [PATCH -V2 08/13] fsnotify: include pathnames with entries when possible Eric Paris
2009-03-27 20:05 ` [PATCH -V2 09/13] fsnotify: add correlations between events Eric Paris
2009-04-07 23:06 ` Andrew Morton
2009-03-27 20:06 ` [PATCH -V2 10/13] fsnotify: allow groups to add private data to events Eric Paris
2009-03-27 20:06 ` [PATCH -V2 11/13] fsnotify: fsnotify marks on inodes pin them in core Eric Paris
2009-03-27 20:06 ` Eric Paris [this message]
2009-04-07 23:06 ` [PATCH -V2 12/13] fsnotify: handle filesystem unmounts with fsnotify marks Andrew Morton
2009-03-27 20:06 ` [PATCH -V2 13/13] inotify: reimplement inotify using fsnotify Eric Paris
2009-04-07 23:06 ` Andrew Morton
2009-04-07 23:06 ` [PATCH -V2 01/13] mutex: add atomic_dec_and_mutex_lock Andrew Morton
2009-04-28 20:08 ` Andrew Morton
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=20090327200611.32007.38991.stgit@paris.rdu.redhat.com \
--to=eparis@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hch@infradead.org \
--cc=john@johnmccutchan.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rlove@rlove.org \
--cc=sfr@canb.auug.org.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome