On Wed, Jan 15, 2025 at 10:56:08AM -0800, Boris Burkov wrote:
> Hello,
>
> If we run the following C code:
>
> unshare(CLONE_NEWNS);
> int fd = open("/dev/loop0", O_RDONLY)
> unshare(CLONE_NEWNS);
>
> Then after the second unshare, the mount hierarchy created by the first
> unshare is fully dereferenced and gets torn down, leaving the file
> pointed to by fd with a broken dentry.
No, it does not. dentry is just fine and so's mount - it is not
attached to anything, but it's alive and well.
> Specifically, subsequent calls to d_path on its path resolve to
> "/loop0".
> My question is:
> Is this expected behavior with respect to mount reference counts and
> namespace teardown?
Yes. Again, mount is still alive; it is detached, but that's it.
> If I mount a filesystem and have a running program with an open file
> descriptor in that filesystem, I would expect unmounting that filesystem
> to fail with EBUSY, so it stands to reason that the automatic unmount
> that happens from tearing down the mount namespace of the first unshare
> should respect similar semantics and either return EBUSY or at least
> have the lazy umount behavior and not wreck the still referenced mount
> objects.
Lazy umount is precisely what is happening. Referenced mount object is
there as long as it is referenced.
