Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934297AbdC3P2S (ORCPT ); Thu, 30 Mar 2017 11:28:18 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:33650 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934136AbdC3PX0 (ORCPT ); Thu, 30 Mar 2017 11:23:26 -0400 From: Djalal Harouni To: Linux Kernel Mailing List , Andy Lutomirski , Alexey Gladkov , Al Viro , , Andrew Morton Cc: Linux API , , Oleg Nesterov , Pavel Emelyanov , James Bottomley , Kees Cook , Dongsu Park , Ingo Molnar , Michal Hocko , Alexey Dobriyan , kernel-hardening@lists.openwall.com, linux-security-module@vger.kernel.org, Djalal Harouni Subject: [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace Date: Thu, 30 Mar 2017 17:22:55 +0200 Message-Id: <1490887379-25880-1-git-send-email-tixxdz@gmail.com> X-Mailer: git-send-email 2.5.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2229 Lines: 69 Hi, This RFC can be applied on top of Linus' tree 89970a04d7 This RFC implements support for multiple separate proc instances inside the same pid namespace. This allows to solve lot of problems that today's use case face. Historically procfs was tied to pid namespaces, and mount options were propagated to all other procfs instances in the same pid namespace. This solved several use cases in that time. However today we face new problems, there are mutliple container implementations there, some of them want to hide pid entries, others want to hide non-pid entries, others want to have sysctlfs, others want to share pid namespace with private procfs mounts. All these with current implementation won't work since all options will be propagated to all procfs mounts. This series allow to have new instances of procfs per pid namespace where each instance can have its own mount option inside the same pid namespace. This was also suggested by Andy Lutomirski. Now: $ sudo mount -t proc -o unshare,hidepid=2 none /test The option 'unshare' will allow to mount a new instance of procfs inside the same pid namespace. Before: $ stat /proc/slabinfo File: ‘/proc/slabinfo’ Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: 4h/4d Inode: 4026532046 Links: 1 $ stat /test3/slabinfo File: ‘/test3/slabinfo’ Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: 4h/4d Inode: 4026532046 Links: 1 After: $ stat /proc/slabinfo File: ‘/proc/slabinfo’ Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: 4h/4d Inode: 4026532046 Links: 1 $ stat /test3/slabinfo File: ‘/test3/slabinfo’ Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: 31h/49d Inode: 4026532046 Links: 1 Any better name for the option 'unshare' ? suggestions ? I was going to use 'version=2' but then this may sound more like a proc2 fs which currently impossible to implement since it will share locks with the old proc. Al, Eric any comments please ? [Patch RFC 4/4] proc: support flushing dcache entries of a task on multiple procfs mounts Is maybe not needed, and I have to test it further. Thanks!