On Tue, Apr 18, 2023 at 9:57 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, 18 Apr 2023 at 17:57, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > On Tue, Apr 18, 2023 at 11:54 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > - mount ID's do not uniquely identify a mount across time > > > o when a mount is deleted, the ID can be immediately reused > > > > > > The following are the minimal requirements needed to fix the above issues: > > > > > > 1) create a new ID for each mount that is unique across time; lets > > > call this umntid > > > > > > > Do you reckon we just stop recycling mntid? > > Do we also need to make it 64bit? > > statx() has already allocated 64bit for stx_mnt_id. > > In that case, should name_to_handle_at() return a truncated mnt_id? > > I'm not sure it's realistic to implement the new 64bit ID such that > the truncated value retains the properties of the previous mount ID > implementation. > > I think the only sane option is to leave the old mnt_id alone and add > a new 64bit one that is assigned from an atomic counter at allocation > and looked up using a hash table. > At the risk of shoehorning, that sounds a bit like file_handle of a mount. Meaning that it could be the result of name_to_handle_at(...,&mount_handle, &mount_id, AT_MNTID) We can possibly use open_by_handle_at() to get a mountfd from mount_handle - not sure if that makes sesnse. [...] > > > 3) allow querying mount parameters via umntid I forgot to mention in the context of this topic, that there was a topic proposal about using "BFP iterator" [1] to query fs/mount info. I don't know if that can be used to get namespace change notifications or if it meets other requirements (i.e. permissions), but wanted to mention it here. I think we can discuss both topics in the same session. Thanks, Amir. [1] https://lore.kernel.org/linux-fsdevel/0a6f0513-b4b3-9349-cee5-b0ad38c81d2e@xxxxxxxxxxxxxxx/
