On Tue, Dec 3, 2024 at 12:40 PM Karel Zak <kzak@xxxxxxxxxx> wrote: > > > Thank you for working on this. > > On Thu, Nov 28, 2024 at 03:39:59PM GMT, Miklos Szeredi wrote: > > To monitor an entire mount namespace with this new interface, watches need > > to be added to all existing mounts. This can be done by performing > > listmount()/statmount() recursively at startup and when a new mount is > > added. > > It seems that maintaining a complete tree of nodes on large systems > with thousands of mountpoints is quite costly for userspace. It also > appears to be fragile, as any missed new node (due to a race or other > reason) would result in the loss of the ability to monitor that part > of the hierarchy. Let's imagine that there are new mount nodes added > between the listmount() and fanotify_mark() calls. These nodes > will be invisible. That should not happen if the monitor does: 1. set fanotify_mark() on parent mount to get notified on new child mounts 2. listmount() on parent mount to list existing children mounts I think that is how Miklos designed the API, but not certain. > > It would be beneficial to have a "recursive" flag that would allow for > opening only one mount node and receiving notifications for the entire > hierarchy. (I have no knowledge about fanotify, so it is possible that > this may not be feasible due to the internal design of fanotify.) > This can be challenging, but if it is acceptable to hold the namespace mutex while setting all the marks (?) then maybe. What should be possible is to set a mark on the mount namespace to get all the mount attach/detach events in the mount namespace and let userspace filter out the events that are not relevant to the subtree of interest. Thanks, Amir.
