From: Alexey Gladkov <firstname.lastname@example.org>
To: Christian Brauner <email@example.com>
Cc: "Eric W. Biederman" <firstname.lastname@example.org>,
"Kees Cook" <email@example.com>,
"Linux Containers" <firstname.lastname@example.org>,
"Alexander Viro" <email@example.com>,
"Andy Lutomirski" <firstname.lastname@example.org>,
"Linux FS Devel" <email@example.com>,
"Alexey Dobriyan" <firstname.lastname@example.org>,
"Stéphane Graber" <email@example.com>
Subject: Re: [PATCH 0/2] proc: use subset option to hide some top-level procfs entries
Date: Fri, 5 Jun 2020 02:28:06 +0200 [thread overview]
Message-ID: <20200605002806.sjxfle7w7v5rdlge@comp-core-i7-2640m-0182e6> (raw)
On Thu, Jun 04, 2020 at 11:32:20PM +0200, Christian Brauner wrote:
> > Is it desirable to have meminfo and cpuinfo as they are today or do
> > people want them to reflect the ``container'' context. So that
> > applications like the JVM don't allocation too many cpus or don't try
> > and consume too much memory, or run on nodes that cgroups current make
> > unavailable.
> > Are there any users or planned users of this functionality yet?
> > I am concerned that you might be adding functionality that no one will
> > ever use that will just add code to the kernel that no one cares about,
> > that will then accumulate bugs. Having had to work through a few of
> > those cases to make each mount of proc have it's own super block I am
> > not a great fan of adding another one.
> > If the runc, lxc and other container runtime folks can productively use
> > such and option to do useful things and they are sensible things to do I
> > don't have any fundamental objection. But I do want to be certain this
> > is a feature that is going to be used.
> I'm not sure Alexey is introducing virtualized meminfo and cpuinfo (but
> I haven't had time to look at this patchset).
No. Not yet :) I just suggest a way to restrict access to files in the
procfs inside a container about which you know nothing.
> In any case, we are currently virtualizing:
> for each container with a tiny in-userspace filesystem LXCFS
> ( https://github.com/lxc/lxcfs )
> and have been doing that for years.
I know about it. The reason for the appearance of such a solution is also
> Having meminfo and cpuinfo virtualized in procfs was something we have
> been wanting for a long time and there have been patches by other people
> (from Siteground, I believe) to achieve this a few years back but were
> I think meminfo and cpuinfo would already be great. And if we're
> virtualizing cpuinfo we also need to virtualize the cpu bits exposed in
> /proc/stat. It would also be great to virtualize /proc/uptime. Right now
> we're achieving this essentially by substracting the time the init
> process of the pid namespace has started since system boot time, minus
> the time when the system started to get the actual reaper age (It's a
> bit more involved but that's the gist.).
> This is all on the topic list for this year's virtual container's
> microconference at Plumber's and I would suggest we try to discuss the
> various requirements for something like this there. (I'm about to send
> the CFP out.)
next prev parent reply other threads:[~2020-06-05 0:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-04 20:04 [PATCH 0/2] proc: use subset option to hide some top-level procfs entries Alexey Gladkov
2020-06-04 20:04 ` [PATCH 1/2] " Alexey Gladkov
2020-06-05 2:19 ` kernel test robot
2020-06-05 2:19 ` [PATCH] proc: fix boolreturn.cocci warnings kernel test robot
2020-06-04 20:04 ` [PATCH 2/2] docs: proc: update documentation about subset= parameter Alexey Gladkov
2020-06-04 20:33 ` [PATCH 0/2] proc: use subset option to hide some top-level procfs entries Eric W. Biederman
2020-06-04 21:32 ` Christian Brauner
2020-06-05 0:28 ` Alexey Gladkov [this message]
2020-06-05 0:08 ` Alexey Gladkov
2020-06-05 4:17 ` Eric W. Biederman
2020-06-05 14:47 ` Alexey Gladkov
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).