adding mount notification to fanotify?

adding mount notification to fanotify?

[Miklos Szeredi]

Here's David's patch, which introduces new infrastructure for this purpose:

https://lore.kernel.org/all/158204559631.3299825.5358385352169781990.stgit@warthog.procyon.org.uk/

I'm wondering if this could be added to fsnotify/fanotify instead?

After all, the events are very similar, except it's changes to the
mount tree, not the dentry tree that need to be reported.

Thanks,
Miklos

Re: adding mount notification to fanotify?

[Amir Goldstein]

On Thu, May 5, 2022 at 7:28 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> Here's David's patch, which introduces new infrastructure for this purpose:
>
> https://lore.kernel.org/all/158204559631.3299825.5358385352169781990.stgit@warthog.procyon.org.uk/
>
> I'm wondering if this could be added to fsnotify/fanotify instead?

I suppose we could.
Speaking of David's patch, I think that getting fanotify events via watch_queue
instead of read() could also be a nice improvement.

>
> 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

Thanks,
Amir.

Re: adding mount notification to fanotify?

[Jan Kara]

On Thu 05-05-22 08:41:09, Amir Goldstein wrote:
> On Thu, May 5, 2022 at 7:28 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > Here's David's patch, which introduces new infrastructure for this purpose:
> >
> > https://lore.kernel.org/all/158204559631.3299825.5358385352169781990.stgit@warthog.procyon.org.uk/
> >
> > 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@suse.com>
SUSE Labs, CR