Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1710639ybg; Thu, 4 Jun 2020 17:31:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbepujwJZVvU5hrlrLMl6ktCoY2XQD/YB6vsUn6dTRdkYaR4hu/e14jgNBCqmYVUbPOh+L X-Received: by 2002:a17:906:15d8:: with SMTP id l24mr6091802ejd.479.1591317066574; Thu, 04 Jun 2020 17:31:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591317066; cv=none; d=google.com; s=arc-20160816; b=ENdk3hZ+TSVjztVd2on8oLoDe7RbVtUWg6hx4Yx8p/S1b5F0qHTUypPisadR1PrKHE 2YQDpbcS7hNjVOb+lguNAm3sz8XcAT+CptFJFLv85LTZi6kFHjL3BnQ0KAqeNjA2p+Hq IlmtfrHBMFdrY8o5TNOYe64GIh1VPbXvU7NhXTHZbpQ+9Lit2VLaPZS//g7LZhuA3t5g /KG5zivNKNqgzFrcc+81hyeiGvw8oXouNRWWH79P4b8wz36I8NWiKj8fvHJ3fk0EO9mj hkcV6YmmZ120yiYwFUKOSELYEJYhMDudsC499WIlyxOR6A4/ZVksPCuzEnGbMsjaTy/9 cuDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=2E1s+NDJ6ylm1Vk3ZI+qhK96dR7FRmzZz1ektUZoKI4=; b=EIOmwjxASY2qPe7bWQ+cY0t3O7L49iMFA6BQkUC1QJTnLs73ewxJ6i9TCXPnW6x2ej XUOR4WjsUSM+ZYomPJyoUeRJO6AojIqbBqbcOK9LuC0xO1WnEWNOZ5HOaSREVtsgtsYf WqUeSKuP1wDe4QbtiUM0HznMjeu6mFhJAgEwI/M517Zu5/G8l1ufnuBY+a8GaEYif7df twL56dNy3MtKVlbocXxNBCJhJJirEczqOmgy95ZtA4cY4pJkdbwLUNKjI4lpKuZd4equ q7t3Vkko5TGrW41Fa5YXfM/TwO9I7c30KFyj4fDK6pF370KfA08T/GI0tEm1tJGF4Ju7 C1Kg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s12si2232112ejx.234.2020.06.04.17.30.43; Thu, 04 Jun 2020 17:31:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726135AbgFEA2N (ORCPT + 99 others); Thu, 4 Jun 2020 20:28:13 -0400 Received: from raptor.unsafe.ru ([5.9.43.93]:36434 "EHLO raptor.unsafe.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726016AbgFEA2N (ORCPT ); Thu, 4 Jun 2020 20:28:13 -0400 Received: from comp-core-i7-2640m-0182e6 (ip-89-102-33-211.net.upcbroadband.cz [89.102.33.211]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by raptor.unsafe.ru (Postfix) with ESMTPSA id 1EDA7209AF; Fri, 5 Jun 2020 00:28:10 +0000 (UTC) Date: Fri, 5 Jun 2020 02:28:06 +0200 From: Alexey Gladkov To: Christian Brauner Cc: "Eric W. Biederman" , Kees Cook , Linux Containers , LKML , Alexander Viro , Andy Lutomirski , Linux FS Devel , Alexey Dobriyan , =?utf-8?B?U3TDqXBoYW5l?= Graber Subject: Re: [PATCH 0/2] proc: use subset option to hide some top-level procfs entries Message-ID: <20200605002806.sjxfle7w7v5rdlge@comp-core-i7-2640m-0182e6> References: <20200604200413.587896-1-gladkov.alexey@gmail.com> <87ftbah8q2.fsf@x220.int.ebiederm.org> <20200604213220.grcaldlxz54jyd3o@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200604213220.grcaldlxz54jyd3o@wittgenstein> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (raptor.unsafe.ru [5.9.43.93]); Fri, 05 Jun 2020 00:28:11 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > /proc/cpuinfo > /proc/diskstats > /proc/loadavg > /proc/meminfo > /proc/stat > /proc/swaps > /proc/uptime > 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 clear. > 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 > disregarded. > > 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.) > > Christian > -- Rgrds, legion