Hi, On Mon 10-10-16 22:12:57, Amir Goldstein wrote: > This series is a prep work for using fanotify to monitor all > events in a file system with a single watch. > > The end result is indented to be an alternative to the recursive > inotify watches scheme, which has its problems. > > This first part adds support for most inotify events to fanotify > when watching a directory. Well, and how is this better than what inotify supports? The proclaimed advantage of fanotify() was that you get open file handle in the event which prevents races when directory tree changes before you manage to process inotify event. However with directory changes, you are again starting to report names and so things become racy again. So I don't quite see a value of reimplementing this in fanotify. The only benefit I see is that you can watch the whole mountpoint with one watch instead of having to add watch to every directory. Is that such a huge win? What is a use case for that? > The next part will add support for watching a super block, > which is not the same as watching a mount point. Careful here. In the world of user namespaces and containers you have to be really careful so that events from one container don't leak into another container despite they live in the same physical filesystem, just a different bind mount. I believe chroot / bind mounts was one of the reasons why fanotify ended with mountpoints and not with superblocks. But I guess Eric or Al remember this better. > I am posting this WIP to get feedback on the idea and to find > out if there are any users out there interested in the improved > fanotify capabilities and/or in the super block monitoring > use case. Well, I hope you have some usecases in mind when you propose this ;) I've been asked about fanotify for superblocks but so far I think that doing it in kernel would be a headache (mostly security-wise) and doing it in userspace - watch every mountpoint in /proc/mounts - may be less error-prone. Honza > > Amir Goldstein (7): > fsnotify: pass dentry instead of inode when available > fsnotify: annotate filename events > fanotify: new init flag FAN_EVENT_INFO_PARENT > fanotify: store mount point from which an inode watch was added > fanotify: support events with data type FSNOTIFY_EVENT_DENTRY > fanotify: add support for create/attrib/rename/delete events > fanotify: pass filename info for filename events > > fs/notify/fanotify/fanotify.c | 85 +++++++++++++++++++++++++++++++---- > fs/notify/fanotify/fanotify.h | 24 +++++++++- > fs/notify/fanotify/fanotify_user.c | 92 ++++++++++++++++++++++++++++++++++---- > fs/notify/fdinfo.c | 4 +- > fs/notify/fsnotify.c | 2 +- > fs/notify/inode_mark.c | 1 + > fs/notify/mark.c | 15 +++++-- > include/linux/fsnotify.h | 46 ++++++++++++++----- > include/linux/fsnotify_backend.h | 24 +++++++--- > include/uapi/linux/fanotify.h | 41 ++++++++++++++--- > 10 files changed, 287 insertions(+), 47 deletions(-) > > -- > 2.7.4 > -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
