Messages in this thread | | | Subject | Re: [RFC][PATCH] inotify 0.10.0 | From | John McCutchan <> | Date | Tue, 28 Sep 2004 16:35:40 -0400 |
| |
On Tue, 2004-09-28 at 13:38, Mike Waychison wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John McCutchan wrote: > | > | --Why Not dnotify and Why inotify (By Robert Love)-- > | > > | * inotify has an event that says "the filesystem that the item you were > | watching is on was unmounted" (this is particularly cool). > > | +++ linux/fs/super.c 2004-09-18 02:24:33.000000000 -0400 > | @@ -36,6 +36,7 @@ > | #include <linux/writeback.h> /* for the emergency remount stuff */ > | #include <linux/idr.h> > | #include <asm/uaccess.h> > | +#include <linux/inotify.h> > | > | > | void get_filesystem(struct file_system_type *fs); > | @@ -204,6 +205,7 @@ > | > | if (root) { > | sb->s_root = NULL; > | + inotify_super_block_umount (sb); > | shrink_dcache_parent(root); > | shrink_dcache_anon(&sb->s_anon); > | dput(root); > > This doesn't seem right. generic_shutdown_super is only called when the > last instance of a super is released. If a system were to have a > filesystem mounted in two locations (for instance, by creating a new > namespace), then the umount and ignore would not get propagated when one > is unmounted. > > How about an approach that somehow referenced vfsmounts (without having > a reference count proper)? That way you could queue messages in > umount_tree and do_umount..
I was not aware of this subtlety. You are right, we should make sure events are sent for every unmount, not just the last.
John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |