From: Bhavik Sachdev <b.sachdev1904@gmail.com>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Aleksa Sarai <cyphar@cyphar.com>,
Bhavik Sachdev <b.sachdev1904@gmail.com>,
Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Jan Kara <jack@suse.cz>, John Garry <john.g.garry@oracle.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
"Darrick J . Wong" <djwong@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Ingo Molnar <mingo@kernel.org>, Andrei Vagin <avagin@gmail.com>,
Alexander Mikhalitsyn <alexander@mihalicyn.com>
Subject: [PATCH v2 0/1] statmount: mountinfo for "unmounted" mounts
Date: Sat, 11 Oct 2025 18:16:10 +0530 [thread overview]
Message-ID: <20251011124753.1820802-1-b.sachdev1904@gmail.com> (raw)
By "unmounted" mounts we mean mounts that have been unmounted using
umount2(mnt, MNT_DETACH) but we still have file descriptors to files on
that mount. We want to add the ability to handle such mounts in CRIU
(Checkpoint/Restore in Userspace).
Currently, we have no way to get mount info for these mounts as they do
not appear in /proc/<pid>/mountinfo and statmount does not work on them.
We solve this problem by introducing a file descriptor parameter to
statmount, along with a STATMOUNT_FD flag. Even if this file descriptor
is on a "unmounted" mount we are still able to get mountinfo for the
mount. We report the mountpoint of the mount to be "[detached]" and
mnt_ns_id to be 0.
v1 of this patchset, took a different approach and introduced a new
umount_mnt_ns, to which "unmounted" mounts would be moved to (instead of
their namespace being NULL) thus allowing them to be still available via
statmount:
https://lore.kernel.org/linux-fsdevel/20251002125422.203598-1-b.sachdev1904@gmail.com/
That approach complicated namespace locking and modified performance
sensitive code.
See: https://lore.kernel.org/linux-fsdevel/7e4d9eb5-6dde-4c59-8ee3-358233f082d0@virtuozzo.com/
Christian also talked about a separate approach of tying the _lifetime_
of the mount namespace to the lifetime of the unmounted mounts through
the passive reference count by moving them to a separate rb_root
`unmounted` in the namespace instance.
This approach has a few problems, some of them are:
1. It further extends the scope of the namespace semaphore.
2. Weird to be able to statmount() via mount id if the mount namespace
is dead.
For a more complete description, see:
https://lore.kernel.org/linux-fsdevel/20251006-erlesen-anlagen-9af59899a969@brauner/
Aleska Sarai also pointed out that this fd based approach is similiar to
the fstatfs(2) which returns information about a mounted filesystem when
given a fd open on that filesystem.
https://lore.kernel.org/linux-fsdevel/2025-10-07-lavish-refried-navy-journey-EqHk9K@cyphar.com/
We use this patchset with CRIU to support checkpoint/restore of
"unmounted" mounts in this pull request:
https://github.com/checkpoint-restore/criu/pull/2754.
All these patches are also available in this branch on github:
https://github.com/bsach64/linux/tree/statmount-fd-v2
Bhavik Sachdev (1):
statmount: accept fd as a parameter
fs/namespace.c | 80 ++++++++++++++++++++++++++++----------
include/uapi/linux/mount.h | 8 ++++
2 files changed, 67 insertions(+), 21 deletions(-)
--
2.51.0
next reply other threads:[~2025-10-11 12:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-11 12:46 Bhavik Sachdev [this message]
2025-10-11 12:46 ` [PATCH v2 1/1] statmount: accept fd as a parameter Bhavik Sachdev
2025-10-21 12:11 ` Christian Brauner
2025-10-22 15:39 ` Bhavik Sachdev
2025-10-22 16:32 ` Miklos Szeredi
2025-10-22 18:12 ` Bhavik Sachdev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251011124753.1820802-1-b.sachdev1904@gmail.com \
--to=b.sachdev1904@gmail.com \
--cc=acme@redhat.com \
--cc=alexander@mihalicyn.com \
--cc=avagin@gmail.com \
--cc=brauner@kernel.org \
--cc=cyphar@cyphar.com \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=john.g.garry@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=ptikhomirov@virtuozzo.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.