From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
To: Christian Brauner <christian.brauner@ubuntu.com>,
David Howells <dhowells@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
Michael Kerrisk <mtk.manpages@gmail.com>,
Andrew Vagin <avagin@virtuozzo.com>
Subject: Re: [PATCH 0/4] fs: add mount_setattr()
Date: Thu, 1 Oct 2020 17:17:53 +0300 [thread overview]
Message-ID: <8f815e88-d51d-9f70-89f1-a7f54b1200ce@virtuozzo.com> (raw)
In-Reply-To: <20200714161415.3886463-1-christian.brauner@ubuntu.com>
>
> mount_setattr() can be expected to grow over time and is designed with
> extensibility in mind. It follows the extensible syscall pattern we have
> used with other syscalls such as openat2(), clone3(),
> sched_{set,get}attr(), and others.
> The set of mount options is passed in the uapi struct mount_attr which
> currently has the following layout:
>
> struct mount_attr {
> __u64 attr_set;
> __u64 attr_clr;
> __u32 propagation;
> __u32 atime;
> };
>
We probably can rework "mnt: allow to add a mount into an existing
group" (MS_SET_GROUP https://lkml.org/lkml/2017/1/23/712) to an
extension mount_setattr. Do anyone have any objections?
We need it in CRIU because it is a big problem to restore complex mount
trees with complex propagation flags (see my LPC talk for details
https://linuxplumbersconf.org/event/7/contributions/640/) of
system-containers.
If we allow set(copy) sharing options we can separate mount tree restore
and propagation restore and everything becomes much simpler. (And we
already have CRIU implementation based on it, which helps with variety
of bugs with mounts we previously had.
https://src.openvz.org/projects/OVZ/repos/criu/browse/criu/mount-v2.c#880)
I've also tried to consider another approach
https://github.com/Snorch/linux/commit/84886f588527b062993ec3e9760c879163852518
to disable actual propagation while restoring the mount tree. But with
this approach it looks like it would be still hard to restore in CRIU
because: With "MS_SET_GROUP" we don't care about roots. Imagine we have
mount A (shared_id=1, root="/some/sub/path") and mount B (master_id=1,
root="/some/other/sub/path", with MS_SET_GROUP we can copy sharing from
mount A to B and make B MS_SLAVE to restore them. In case we want to do
the same with only inheritance we would have to have some helper mount
in this share C (shared_id=1, root="/") so that B can inherit this share...
--
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.
prev parent reply other threads:[~2020-10-01 14:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 16:14 [PATCH 0/4] fs: add mount_setattr() Christian Brauner
2020-07-14 16:14 ` [PATCH] mount_setattr.2: New manual page documenting the mount_setattr() system call Christian Brauner
2020-07-21 9:59 ` Michael Kerrisk (man-pages)
2020-07-14 16:14 ` [PATCH 1/4] namespace: take lock_mount_hash() directly when changing flags Christian Brauner
2020-07-14 16:49 ` Jann Horn
2020-07-14 16:14 ` [PATCH 2/4] namespace: only take read lock in do_reconfigure_mnt() Christian Brauner
2020-07-14 16:14 ` [PATCH 3/4] fs: add mount_setattr() Christian Brauner
2020-07-15 8:29 ` Geert Uytterhoeven
2020-07-15 11:02 ` Christian Brauner
2020-07-14 16:14 ` [PATCH 4/4] tests: add mount_setattr() selftests Christian Brauner
2020-07-19 17:10 ` [PATCH 0/4] fs: add mount_setattr() Al Viro
2020-07-19 17:55 ` Christian Brauner
2020-10-01 14:17 ` Pavel Tikhomirov [this message]
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=8f815e88-d51d-9f70-89f1-a7f54b1200ce@virtuozzo.com \
--to=ptikhomirov@virtuozzo.com \
--cc=avagin@virtuozzo.com \
--cc=christian.brauner@ubuntu.com \
--cc=dhowells@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).