On Thu, Oct 5, 2023 at 6:52 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Thu, 28 Sept 2023 at 15:03, Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote: > > > > If a mount is released then its mnt_id can immediately be reused. This is > > bad news for user interfaces that want to uniquely identify a mount. > > > > Implementing a unique mount ID is trivial (use a 64bit counter). > > Unfortunately userspace assumes 32bit size and would overflow after the > > counter reaches 2^32. > > > > Introduce a new 64bit ID alongside the old one. Initialize the counter to > > 2^32, this guarantees that the old and new IDs are never mixed up. > > It occurred to me that it might make sense to make this counter > per-namespace. That would allow more separation between namespaces, > like preventing the observation of mount creations in other > namespaces. > Preventing the observation of mount creations in other mount namespaces is independent of whether a global mntid namespace is used. > Does a global number make any sense? > I think global mntid namepsace makes notifications API a lot easier. A process (e.g. systemd) may set marks to watch new mounts on different mount namespaces. If mntid could collide in different mount namepsaces, we will either need to describe the mount namespace in the event or worse, map child mount namespace mntid to parent mount namespace like with uids. If we use a global mntid namespace, multi mount namespace watching becomes much much easier. Regarding the possible scopes for watching added/removed mounts we could support: - watch parent mount for children mounts (akin to inotify directory watch) - watch all mounts of a filesystem - watch all mounts in mount namespace - watch on entire system Not sure which of the above we will end up implementing, but the first two can use existing fanotify mount/sb marks. Thanks, Amir.
