On Thu 05-05-22 08:41:09, Amir Goldstein wrote: > On Thu, May 5, 2022 at 7:28 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > Here's David's patch, which introduces new infrastructure for this purpose: > > > > https://lore.kernel.org/all/158204559631.3299825.5358385352169781990.stgit@xxxxxxxxxxxxxxxxxxxxxx/ > > > > I'm wondering if this could be added to fsnotify/fanotify instead? > > I suppose we could. I'm not so sure. We could definitely add fanotify event for changes in the superblock (like watch for RO vs RW state, mount option changes, etc. of a particular sb). However the general "was anything mounted/unmounted in the subtree of this mount" seems to have rather different properties than common fanotify events. For fanotify if would be natural to have events like "was anything mounted on this dir?" or "was anything mounted on some dir of this superblock?". Besides this philosophical objection, communicating general "something got mounted in the subtree" through fanotify has the problem that we would have hard time gathering and reporting what has changed and where information - that would basically require completely separate info structures attached to events. So there is some overlap but I'm not sure it is large enough. > Speaking of David's patch, I think that getting > fanotify events via watch_queue instead of read() could also be a nice > improvement. What would be advantages? > > After all, the events are very similar, except it's changes to the > > mount tree, not the dentry tree that need to be reported. > > > > There is already one precedent to event on mount tree change in fsnotify - > inotify IN_UNMOUNT Yes, events for superblock have precedent. But since fanotify is all build around watches on objects, I'm not sure general mount notification really fits well. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
