From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932552AbdBVLqb (ORCPT ); Wed, 22 Feb 2017 06:46:31 -0500 Received: from mozilla-myt-1.haze.yandex.net ([77.88.23.115]:54150 "EHLO mail.unsafe.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932291AbdBVLqX (ORCPT ); Wed, 22 Feb 2017 06:46:23 -0500 Date: Wed, 22 Feb 2017 12:53:47 +0100 From: Alexey Gladkov To: Oleg Nesterov Cc: Linux Kernel Mailing List , "Kirill A. Shutemov" , Vasiliy Kulikov , Al Viro , "Eric W. Biederman" , Pavel Emelyanov Subject: Re: [PATCH] Add pidfs filesystem Message-ID: <20170222115346.GE3279@comp-core-i7-2640m-0182e6.fortress> References: <20170218225307.GA10345@comp-core-i7-2640m-0182e6.fortress> <20170221145746.GA31914@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170221145746.GA31914@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 21, 2017 at 03:57:47PM +0100, Oleg Nesterov wrote: > On 02/18, Alexey Gladkov wrote: > > > > This patch allows to mount only the part of /proc related to pids > > without rest objects. Since this is an addon to /proc, flags applied to > > /proc have an effect on this pidfs filesystem. > > I leave this to you and Eric, but imo it would be nice to avoid another > filesystem. > > > Why not implement it as another flag to /proc ? > > > > The /proc flags is stored in the pid_namespace and are global for > > namespace. It means that if you add a flag to hide all except the pids, > > then it will act on all mounted instances of /proc. > > But perhaps we can use mnt_flags? For example, lets abuse MNT_NODEV, see > the simple patch below. Not sure it is correct/complete, just to illustrate > the idea. > > With this patch you can mount proc with -onodev and it will only show > pids/self/thread_self: > > # mkdir /tmp/D > # mount -t proc -o nodev none /tmp/D > # ls /tmp/D > 1 11 13 15 17 19 20 22 24 28 3 31 33 4 56 7 9 thread-self > 10 12 14 16 18 2 21 23 27 29 30 32 34 5 6 8 self > # cat /tmp/D/meminfo > cat: /tmp/D/meminfo: No such file or directory > # ls /tmp/D/irq > ls: cannot open directory /tmp/D/irq: No such file or directory > > No? I'm embarrassed that we start the change procfs by abuse something. It is very difficult to explain why this option leads to such consequences on procfs. Also with this change it won't be the same procfs. We can't to name it as procfs because procfs have cpuinfo, meminfo, etc. What do you think about this ? -- Rgrds, legion