From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755506AbcHBAIm (ORCPT ); Mon, 1 Aug 2016 20:08:42 -0400 Received: from mail-db5eur01on0139.outbound.protection.outlook.com ([104.47.2.139]:36032 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755470AbcHBAIO (ORCPT ); Mon, 1 Aug 2016 20:08:14 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=avagin@virtuozzo.com; Date: Mon, 1 Aug 2016 16:32:49 -0700 From: Andrew Vagin To: Alban Crequy CC: Andrey Vagin , "linux-kernel@vger.kernel.org" , James Bottomley , Serge Hallyn , Linux API , "Linux Containers" , Alexander Viro , , "Eric W. Biederman" , , "Michael Kerrisk (man-pages)" , , Alban Crequy Subject: Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces Message-ID: <20160801233248.GB32309@outlook.office365.com> References: <1468520419-28220-1-git-send-email-avagin@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) X-Originating-IP: [162.246.95.100] X-ClientProxiedBy: BY1PR18CA0038.namprd18.prod.outlook.com (10.162.126.48) To DB6PR0801MB1976.eurprd08.prod.outlook.com (10.168.85.149) X-MS-Office365-Filtering-Correlation-Id: ea0c6775-4c66-42a8-5856-08d3ba642fbb X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1976;2:IMulJ3OybLsEMga1TZ6RMzR25tXjwMkSESHOzA6Y3pfR6MZM6+wUZBaNDadCyKcxWXflBkgBOQecF1PpqNqLt986Hzv2LxIIn8Ze0Da/M/nKhNMsZ8Rd6r+M6kIRO1afWRaPjDpycq9kVmy+PeNN+kVWO+3Mgto1CV9SG5seb4hntlgs0CB0Kr9xSoCLPgCy;3:js/PM4HCTkOx8bYA3cRnLPwHPYwssflip5uTWF8+zWlGcTIszfXulg/lv6WNXi4UiXC25/PqtiSXtk3MN00AGL7cErBYZSzHUgpuCWDLeM/IlGn+EMHWf/GRORh3tioj X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0801MB1976; X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1976;25:t9QENjYulVDUSet0g16ojGJBpo6n46krO6ObqV7zMmZCl+lE649hnXgPxyxjPd41guwY7F+r00ApECUlBPEtp+3DR4J+DpmjSebpxg3ph9iOFFxtvAIAeh+RShei0JrFPVOyJ37jq3KsQGoxv/sGbZ+n09oxZbIqCXCmiChH0X6TFwizMEl13B5ZuLz3gcUOBQGK0ZPSsBtbWOi4oHN2aGl92+ucxkid5uOUnkEYm7g3XbcVpM/YTZI3rRKTjKZVN/3WoGVKwo/5gk5M9Qi6wp77xZlnFx+54oRkCBg/akVS3ec4BvJLUePhpOWyTaNnmsb/K1x1+1OoAnidMZF3BFMc4Y4ZuQGxBuLupD9oJngeNeTpDTsTIwagMuVgtCmvcMhXA0qNL5x9MrfB/IC7GjcEOeYU8hUFps7WChlgD6wy2tAEh2biY8HmsfjN6F4XZCgoBN43DVDZEKy0R0rRleOBlNkb6/RtnWJyfc3j/9YtK/XZ7izrnEgHGZIVxzX6DF+kbQTLXyXEeADqNIQHrnLNy/GeB2sCmOpRdL9sGKfs0pIZKVS0fk4zdnuyMzoiGeu4ZAHMd2pfx/lvPuNsBg2VSgqwYC4qRwUuYtCkph5qxkG3nDbOa2yCtAXmh75Gh6gp4HmAm+CpwsXP0KBDnruZ0YsSp3bWOMy4Z4hDTNK+bPq3VeViR3w33bWw7Cg9FHHhY3kQA1IHILBGbYB5zXEyXskUY0tRCFO3uY8coeA5fs6IKEglzFq7TmDfEy2upDer9hhp0Hbn+FrTjpItZQvYnlLdHEzhtKe91BqAxk/eEp+kDPq9q1OoJUbKJFDDNqsFQMDM2u12naaQtipOV50I8nPdTY9OgRI3VEtVkQk= X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1976;31:7t0fTpl1XxjnbDkng+74mDllTGc+yc9sEFa4uJSgG8/wRxkRgqM8WjFf+95u5wEztY2vCHfqS3ISFjte3kcbHE2+Fr6SiWiG15UzZxf2VqMTOvutFB9C36MzLi0UZizOPQhhy16aOJepV4lM6w1UbECNpt0Ga9HBvAzWwgb1e75xkxnoD9qtyfwsj1G7Z5Plke8nKT5C1mXZJD3Tpk6n3A==;4:3ZdTnCEJQW505U5/Utw2NnuooEQlvVr6jiiSV0O4IDEEKvRp7dwR6emYCuERZOs1jsyrZjnz/PjqaNKzcP93+f7QhR2RIffSMGnDNpYnjGSNc06mJHPHp/XS0zn2OlNeVFIpNWMWh+MekxiqJvVbjYNpL4QvdIt4ifLQgKNRSjDgENw8Ehn6Z0xHm6E0W92gBuxOlRWAbtRmJyVwZXEQkA4OQ22BKSdYnYhUczBAghPxKl8tLm1YRiI3HgkhMvLw0pDYBqy/fSArTNOdlxwtLvL24S8pleYY+tfhQvJ9bbUtm49A3tLZ91xfvZdDw+gXOMWWTEK/RhtfHwqSU/6NZhv270jN0DcUP7vpd757kGUsci94IsdPixvId33oqJKjcefPwk0cKfofPXaEICr2na62r1NYbVZ5oef6zcXrrDATRpwDLYcEgnbuwAsYL8StY26NhXZDI01yPmxmUCwcBkyT8UwH5mk8nojCgIisdiw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(198206253151910); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:DB6PR0801MB1976;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0801MB1976; X-Forefront-PRVS: 0021920B5A X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(189002)(24454002)(2906002)(42186005)(19580395003)(19580405001)(50986999)(76176999)(69596002)(54356999)(53416004)(305945005)(7846002)(97736004)(7736002)(586003)(81156014)(8676002)(106356001)(50466002)(7416002)(81166006)(83506001)(77096005)(4326007)(15975445007)(2950100001)(92566002)(9686002)(3846002)(1076002)(68736007)(6116002)(86362001)(33656002)(4001350100001)(66066001)(47776003)(23686003)(101416001)(189998001)(110136002)(105586002)(7099028)(18370500001)(26326002);DIR:OUT;SFP:1102;SCL:1;SRVR:DB6PR0801MB1976;H:outlook.office365.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?koi8-r?Q?1;DB6PR0801MB1976;23:mzd92IvWzb0EQ+I6QrFk/I/KTIInzuLBCF7B8GJoB?= =?koi8-r?Q?A0O5DXeabYpox7c3JTzJtnPgvMfBuKKm0s9stCJ93JA/S4tyVHfmgxp5bNlVqC?= =?koi8-r?Q?zvdZ/9eFijnMXc5bLaG7wC9xOeGY4fFfpZWKbhYuw30Ot3lED8eY9kAd+m9YCP?= =?koi8-r?Q?BP8fJ21Vm6cZi3v+BV1g56WN459tirxBjZ8MFarZaj8fQlS4D6LIGqw1CWlBXR?= =?koi8-r?Q?6z1vyOAjM6M1ixPbyt6dhz6GbZbfrN3iV00TRDcy8Z/nzgxA1VpSzRUQweNi79?= =?koi8-r?Q?99h9aZz/pNyZlh588Dc8GZ4yaSvQRQeo8FUD52BcfCFEZFvNrfot1D9C3Z4tmw?= =?koi8-r?Q?J/JifqezYif4CZDBdP6PZ5dYRBgZ4w0gFeDqwMgjCCWPn9Rhr/BQxe/66rZzWi?= =?koi8-r?Q?7MU3Gu0F8k4sAt9zQbL//vSGBNC3WCU3OjXhBCWCXld4OjmQ1STacPYxW+JANi?= =?koi8-r?Q?D8mH36XcHlyTAEFErIH+Jmwk5Z4D3YPZb3ZVStwM/17LJ6/hs5EM7iOfETU2aZ?= =?koi8-r?Q?XBAx3D1/cEZCxTds4Of8iEWOrEE7FzF4696Hu8icTVj3JHuQN+xIeUkLz0RS7O?= =?koi8-r?Q?Cbhb80LHM+CFfRoGZO5JKcVA7dpFaSnFjFPVwbh9psREzP+4o+96W3bHFW8tni?= =?koi8-r?Q?3zd9xOuCNXCgmpVZay53RIhcwLEajVncGFin9MwuidASQj5V9LRWvoEFivthdP?= =?koi8-r?Q?RVcwNngH6qpJ9zjReD7RFji2yw/sXJIFjFVs+rfxQsOlE1eWUhuVWZZBCaQ9pc?= =?koi8-r?Q?n5r1OPxK4RogZ9ioKr0gPM0rShk/SlZlIM91vDsOTkJZRk/vUonoQRIEUUWGEP?= =?koi8-r?Q?414R3wvRnM8SHKaj9apRl8KP5tDV0lp79VP2BQgN49sIh5DqN83LC91m/f5I/D?= =?koi8-r?Q?A2D353P5wiprP2kr3iY2JCVTVwsH36+hNkTmZ+UzCXRVWreAkL2g79kxkElERa?= =?koi8-r?Q?pLJ+ZnjDzgEPDZ7H3qvZPoyo64VF2oqgIJZY17aE3ZAZWtkTJMSKMzlTYVpaJ9?= =?koi8-r?Q?TF24VA6+bnnYVxeegR9R2Xa1t/FQaAygG8gbMeiXq+gUBeAXAj4x6N/f+ccqul?= =?koi8-r?Q?8e+EfqjLVpvwqO8PcGS1kqun/efTPAL8oiADRKnyVtOGIezAFfwKq6jyZj5gS2?= =?koi8-r?Q?OkreanDglOVBenYxBVXbq//6KF6YOHSVN4hVUnPFHug5nEgXQI9H/xi/Wb2mV4?= =?koi8-r?Q?DHBIjYlrm1p4Ee8xbUnFrrOYEcUQ/bEo8ADMCbqI=3D?= X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1976;6:sHvpBEm6SylBzvL4m3zBoorpkomePRjjvgfO/tkuWJ48D6PAPUs+dkYvprq5yvL24+35XGKfau9tvCX8K4qKEhsZqACYQ6TrOhmOWkliDcU87i0cwWUfffi7ymJ/7L18KCwOHMjo1TTNsrRCZIeMcO2TsyU1GSTBwgeUhGZ95VbF41wbd2dZTbJ01Sffk6bdbYdSEODedbVPK+NQExYNZ9hkrsXIysUmb5E2ur0H9VvT3+swjDzIV5Bw8CfB2WHU9nzlmAzFfNX+eTRy0XPfJgrodWe+zBzKLDRjRyWUjktTW/EuwTNcev+hsxniqEET;5:NbLBfH6gK3RBi0XfGmQwKX83/kcEq3KuBVqNMFwRpvgA7wvS8vmkUh0eKmQP7sZL1359SiQYEy2h58snWyxzH8od9VVIhLszEqlVcH1Ynz6bkXEnglUZUCGJ9kI0t9ZDp2Zi4WWGKtxAaSjRNiAQHQ==;24:t7anQrFGgQ2tS7MAVNocUliGOCxjvoAURXwiJhMIGi/N8Id/JQWn6C3y5s5GuXiCkmSV4BQ6UXBv4xjCF/u81ckdUZFq0g4MQBK/mfUmkcA=;7:7dCDszMGP6zIQdL+BocQkUrEMGSJ/11YYLVnW4AKgbVQpKEJp+iC9990nLRRsdAvH03MdaB4WRcGy4bw3EOaqdJjYqru1N3+ICGA9FapVQJVSUqMY5X794gL4RG0Bjymj8W4TvXuM0VGixzfIZrY5sjZsV479VK6SXWYUIxy44hfsno8C8IIEel1rpXXgm/p9Kz8tKwuwclTCf/8hE63KpIrCeYcghMfcZsfUmHgFTPwSmCJcmb5Oh4GDo1D5yYH SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DB6PR0801MB1976;20:sLRlZ6FOxryIlR/RImksoQWQfe1xlcwKcC6Avu2q4R2qOBnRUiYp1o32v6Jtr2OKQ96yxvy5JjxC/0g2YBS/cacioVbUCJ3lKh32fKxqWo35VKFDYftTRToue+VzRiJn+08akx+9R+zeI+qhsv4CHbGQpxiTQYTa6YYJIdp+h6U= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2016 23:33:02.3442 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1976 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 01, 2016 at 08:20:27PM +0200, Alban Crequy wrote: > Hi, > > On 14 July 2016 at 20:20, Andrey Vagin wrote: > > Each namespace has an owning user namespace and now there is not way > > to discover these relationships. > > > > Pid and user namepaces are hierarchical. There is no way to discover > > parent-child relationships too. > > > > Why we may want to know relationships between namespaces? > > > > One use would be visualization, in order to understand the running system. > > This looks interesting to me because I am interested in representing > in a graphical way the relationship between different mounts in > different mount namespaces (showing the ID, the parent-children > relationships, mount peer groups, the master-slave relationships etc), > specially for containers. The first idea was to take both > /proc/1/mountinfo and /proc/$OTHER_PID/mountinfo and I can correlate > the "shared:" and "master:" fields in the mountinfo files. > > But I cannot read the /proc/$pid/mountinfo of mount namespaces when > there are no processes in those mount namespaces. For example, if > those mount namespaces stay alive only because they contain > "shared&slave" mounts between master mounts and slave mounts that I > can see in /proc/$pid/mountinfo. Fictional example: > > # mntns 1, mountinfo 1 (visible via /proc/1/mountinfo) > 61 0 253:1 / / rw shared:1 > > # mntns 2, mountinfo 2 (not visible via any /proc/$pid/mountinfo) > 731 569 0:75 / / rw master:1 shared:42 > > # mntns 3, mountinfo 3 (not visible via any /proc/${container_pid}/mountinfo) > 762 597 0:82 / / rw master:42 shared:76 > > As far as I understand, I cannot get a reference to the mntns2 fd > because mnt namespaces are not hierarchical, and I cannot get its > /proc/???/mountinfo because no processes live inside. Hi Alban, A mount namespace is alive only if someone lives in it or if it is bind-mounted somewhere. In your case, the kernel destroys mntns2 and adjusts groups for mounts: [root@fc24 zzz]# nsenter --mount=mnt2 -- cat /proc/self/mountinfo | grep zzz 184 183 0:43 / /tmp/zzz/a rw,relatime shared:72 master:70 - tmpfs a rw [root@fc24 zzz]# nsenter --mount=mnt3 -- cat /proc/self/mountinfo | grep zzz 162 161 0:43 / /tmp/zzz/a rw,relatime master:72 - tmpfs a rw [root@fc24 zzz]# umount mnt2 [root@fc24 zzz]# nsenter --mount=mnt3 -- cat /proc/self/mountinfo | grep zzz 162 161 0:43 / /tmp/zzz/a rw,relatime master:70 - tmpfs a rw Thanks, Andrew > > Is there a way around it? Should this use case be handled together? > > Thanks! > Alban > > > Another would be to answer the question: what capability does process X have to > > perform operations on a resource governed by namespace Y? > > > > One more use-case (which usually called abnormal) is checkpoint/restart. > > In CRIU we age going to dump and restore nested namespaces. > > > > There [1] was a discussion about which interface to choose to determing > > relationships between namespaces. > > > > Eric suggested to add two ioctl-s [2]: > >> Grumble, Grumble. I think this may actually a case for creating ioctls > >> for these two cases. Now that random nsfs file descriptors are bind > >> mountable the original reason for using proc files is not as pressing. > >> > >> One ioctl for the user namespace that owns a file descriptor. > >> One ioctl for the parent namespace of a namespace file descriptor. > > > > Here is an implementaions of these ioctl-s. > > > > [1] https://lkml.org/lkml/2016/7/6/158 > > [2] https://lkml.org/lkml/2016/7/9/101 > > > > Cc: "Eric W. Biederman" > > Cc: James Bottomley > > Cc: "Michael Kerrisk (man-pages)" > > Cc: "W. Trevor King" > > Cc: Alexander Viro > > Cc: Serge Hallyn > > > > -- > > 2.5.5 > > > > _______________________________________________ > > Containers mailing list > > Containers@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/containers