> 1. Start a new server instance > 2. Set default response in case of new instance crash > 3. Hand over a ref of the existing group fd to the new instance if the > old instance is running > 4. Start handling events in new instance (*) > 5. Stop handling new events in old instance, but complete pending events > 6. Shutdown old instance I think this should work for our case, we will only need to reconstruct the group/interested mask in case of crash. I can help add the feature for setting different default responses. > Doing this for the mount level would be possible, but TBH, it does not look > like the right object to be setting the moderation on, because even if we did > set a default mask on a mount, it would have been easy to escape it by > creating a bind mount, cloning a new mount namespace, etc. > > What is the reason that you are marking the mount? > Is it so that you could have another "unmoderated" mount to > populate the file conten? > In that case you can opt-in for permission events on sb > and opt-out from permission events on the "unmoderated" mount > and you can also populate the file content with the FMODE_NONOTIFY > fd provided in the permission event. Yes, essentially we surface and monitor read-only bind mounts of specific directories. The current setup opts-in for events per mount (via FAN_MARK_MOUNT), and initial access populates file contents. If theres a way to do this with sb marks we can switch to that, it would simplify things. I saw theres some discussion of similar use-cases in this thread on sb views: https://lore.kernel.org/linux-fsdevel/20201109180016.80059-1-amir73il@xxxxxxxxx/ > I might have had some patches similar to this floating around. > If you are interested in this feature, I could write and test a proper patch. That would be appreciated if its not too much trouble, the approach outlined in sketch should be enough for our use-case (pending the sb vs mount monitoring point you've raised).
