Received: by 10.192.165.148 with SMTP id m20csp1881604imm; Thu, 3 May 2018 06:58:58 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrk9mm0NVTz03/5PeJSP46RqnzVJk1/SYrecnQU7DRnPVAKJOAJlob6NJScFNBBCfAh6QXs X-Received: by 2002:a63:8dc1:: with SMTP id z184-v6mr19366538pgd.114.1525355938860; Thu, 03 May 2018 06:58:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525355938; cv=none; d=google.com; s=arc-20160816; b=rIguClAPdc/RKb9bj8O3oXAYhgW4CqGf93oeke9qDbMk7aL+ZXngXgjdLZDnwwyIw7 486+0MDbQMfXotGIRsxx8tEZDM+cqud8rqCqhcChazN3L3M4TKps+IzJ1uvCcNKb9god h32BXRpRAgoDgZl5P7biw3PRtdsgqRsLFwy+6I1Xj4JTFEWp/Aheo8+yxywbvBa2Pcax f9K4WnbzPc2ceaV7tJ88Rd3umpEKk2OBrH5s/sd/FzuT+frsIh6RKqERFWs/7V7RSadL DfJTmuMZYOJBQpyHedrJWVQwMzhrrYQaR9FLi6tnfp/3wN7QYXYdER0Xzb+77MrcEv1P Juug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=FPiiIhtb5CDoNe76R1yQ5efI+GvCvDQTTwEABRpzXak=; b=I6fQlaSre98WfZE0muMH6T/5OXUumZS9zHb/vpxDkHdtRGMuSTBDKzbOjzKrh1Yp5x Kq0AdUZOxdPOz745jCaIINpw13uOCjAzxJYRfP92zSSa7RZHYEr4Bl1/uoc9kRiUhxi5 R89cB2ksG2FxkUdmo3qaiKeKS3c3cKc6KBQshtnfsoQ+njq0K2VU9ZllkB5urPYns2sh gs0hQoUM0ccUYOsLXjVfN+fRB2UKLRFgQ44UUhgfK+FOWaY50W76l7Nqn1IamGbH2bXN mJGS+GxL1X0HZ/XdtUa2KznvAIC8ds01+pBnkYu+utKKc8kszcjKoBqPH07QeCv+S9yz W1Lg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b73-v6si11602298pga.106.2018.05.03.06.58.15; Thu, 03 May 2018 06:58:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751329AbeECN5s (ORCPT + 99 others); Thu, 3 May 2018 09:57:48 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:43532 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750930AbeECN5o (ORCPT ); Thu, 3 May 2018 09:57:44 -0400 Received: from mail-vk0-f70.google.com ([209.85.213.70]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fEEjv-0001t9-P3 for linux-kernel@vger.kernel.org; Thu, 03 May 2018 13:57:43 +0000 Received: by mail-vk0-f70.google.com with SMTP id u6-v6so14361529vke.7 for ; Thu, 03 May 2018 06:57:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FPiiIhtb5CDoNe76R1yQ5efI+GvCvDQTTwEABRpzXak=; b=M/BdzLz+FfDGlcMQeiOEvlEGqhfXZ3IgXfvHcBPperJ1NmPq3W9wTA/2J68t1qCpit mYUMog/Nzko52g7nrr3YG3R118V3FT6POz9Jp22/8AzTv14X4l+gOMjrXZEWpkhUexto NroVXMhw+3dm1SYmN+tRL2+Fomqg1NlLT9e10QbiN2aBpsbT2OhYXr9/q5vFpCAKF74a m3H3NflEE2FVpEbq50d3k647j/GDUkRj1wumQ2B8o7NiPmvc9jq2FfbZqEnXepGUpR7J iEriwPIqgsdSFKJ2JiceNtL7TQUTaf3lnoCwXmwQ1K4Oka9gp/j7f0I0U5K2DBII9/NQ O2dQ== X-Gm-Message-State: ALQs6tDUdWObVELjxuHqOtj+pxBF8rRpWKgHJQtPzK9H/ZaWFf5jU2oB mhO6hGB84qntvSJhhpO0pahZEmWgkoVoW/SZ3A4RrHbhCou2n1bOrundzBbO6t9lucUBCG1qaPA Rqn4wNU7Hy24XNLb95FZQHxLvwIPS5o7B+Lmg4c1Z7Ge+SvQjLgMEqJmDOg== X-Received: by 2002:a1f:3650:: with SMTP id d77-v6mr21564041vka.167.1525355862798; Thu, 03 May 2018 06:57:42 -0700 (PDT) X-Received: by 2002:a1f:3650:: with SMTP id d77-v6mr21564012vka.167.1525355862437; Thu, 03 May 2018 06:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.171.1 with HTTP; Thu, 3 May 2018 06:57:41 -0700 (PDT) In-Reply-To: <20180503134317.GA30522@ZenIV.linux.org.uk> References: <20180502154239.14013-1-christian.brauner@ubuntu.com> <20180502160939.GU30522@ZenIV.linux.org.uk> <20180503134317.GA30522@ZenIV.linux.org.uk> From: Christian Brauner Date: Thu, 3 May 2018 15:57:41 +0200 Message-ID: Subject: Re: [PATCH 0/6 resend] statfs: handle mount propagation To: Al Viro Cc: Christian Brauner , Linus Torvalds , linux-fsdevel , Linux Kernel Mailing List , Christoph Hellwig , Thomas Gleixner , Kate Stewart , Greg KH , Philippe Ombredanne , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 03, 2018 at 02:43:17PM +0100, Al Viro wrote: > On Thu, May 03, 2018 at 03:04:36PM +0200, Christian Brauner wrote: > > > >From a userspace perspective we often run into the case where we simply > > want to know whether a given mountpoint is MS_SHARED or is MS_SLAVE. > > If it is we remount it as MS_PRIVATE to prevent any propagation from > > happening. We don't care about the peer relationship or how the > > propagation is exactly setup. We only want to prevent any propagation > > from happening. > > So what's to stop you from doing exactly that -- > mount(NULL, "/", NULL, MS_PRIVATE | MS_REC, NULL) > without bothering with statfs() in the first place? It's not like the > damn thing had been costly - it's O(mounts in your namespace) with not > to high constant, and in any case cheaper than allocating all of them > back when you did clone(2). Confused... That's the case for the whole rootfs. But there are cases where I want to leave the rootfs itself alone and only remount some paths. > > > The above case is what I see most often. A more specific use-case is to > > differentiate between MS_SLAVE and MS_SHARED mountpoints. > > Mountpoints that are MS_SLAVE are kept intact and mountpoints that are > > MS_SHARED are made MS_PRIVATE. > > > > For both cases the only way to do this right now is by parsing > > /proc//mountinfo. Yes, it is doable but still it is somewhat costly > > and annoying as e.g. those mount propagation fields are optional. > > Umm... And how would you get the list of mountpoints to feed to statfs() > if not by parsing mountinfo? IDGI... There are cases where you have list of known-mountpoints or paths to check but you don't necessarily know whether they are MS_SHARED or MS_SLAVE. There's also a case where I send a list of fds via SCM_RIGHTS to an isolated process that calls fstatvfs() on these fds to determine their mount flags without changing them but cache this info. Christian