Received: by 10.192.165.148 with SMTP id m20csp812760imm; Wed, 2 May 2018 09:10:10 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo7Lyfljan30KxO2gQCwqw52LUdBAaPYLrfhz6SsyFoa5DZjPNlSmYyvCEhnbSGlN57/OgJ X-Received: by 2002:a63:9854:: with SMTP id l20-v6mr16262079pgo.16.1525277410207; Wed, 02 May 2018 09:10:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525277410; cv=none; d=google.com; s=arc-20160816; b=XePLcl7kk+H4wDrvefa9suCcgHyEpljexAfAUrQ+HIVZF6FLvvgFqHdf5AaZFDu5ka yfyA2343INDsdtiMAbGET+wsRtXyh6iF/mkZWtiJ4sYZO9hJySdFepavtpgoinc7TZp3 E07g81VvsnLppFt2NZc+YD2IctOm+fLv76+9ndsr9DsqnPK2D8X4X+Cag60iw1lbeXwt q2qu1zeb9p662VakSRII4s7zHbVG7X9t628+QbJ0LhDAbUAEHdixK/cvkKdZkds3hZnp z6KBZtnTVZkP5rsYHl0npvj2CdK5YMo64tUX63xQ2Nej7OFRzrkL9DbjnJI585fU1LxY ATTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=5yBtrllCXDaXdxYRt8q6bEOS+BOmT15Iriq0zDUmcBE=; b=UYecpOjGXT/YJbcSI0lUeZiszIc59ZOar4onr5ejFKvkW790pGghUH9dXQSNN464xS WZ5QASVW7Foe0FhA9xbg19xqPr7e0yxuYMgBr0q0Hnl5GSzSHjqpL5coAM41Jz7roajZ rlQOPIC0TPLwNCFLIHH2tsGBBQVhpM/nzJFqk+9C9PymfPas0fhxSKgvmMxO8r9RC9qf fAKGuKFcPGcNKQH9jPBuOL1UiHnIZh0tt4T6kafBELUI81Ez7SsbaT2uuyCMOL6zVNXy PVwgdJmIOgcwHiZDL4JzHDs9QcMPd5u8ssYOxHJTeOQ4ddzm2gzFW6Y7OjSyuN0NvJZN xvVQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n6si6437509pfi.360.2018.05.02.09.09.56; Wed, 02 May 2018 09:10:10 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751932AbeEBQJp (ORCPT + 99 others); Wed, 2 May 2018 12:09:45 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:48450 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751552AbeEBQJl (ORCPT ); Wed, 2 May 2018 12:09:41 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fDuK3-000727-8J; Wed, 02 May 2018 16:09:39 +0000 Date: Wed, 2 May 2018 17:09:39 +0100 From: Al Viro To: Christian Brauner Cc: torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hch@infradead.org, tglx@linutronix.de, kstewart@linuxfoundation.org, gregkh@linuxfoundation.org, pombredanne@nexb.com, linux-api@vger.kernel.org Subject: Re: [PATCH 0/6 resend] statfs: handle mount propagation Message-ID: <20180502160939.GU30522@ZenIV.linux.org.uk> References: <20180502154239.14013-1-christian.brauner@ubuntu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180502154239.14013-1-christian.brauner@ubuntu.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 02, 2018 at 05:42:33PM +0200, Christian Brauner wrote: > Hey, > > This is the second resend of this patchset. I'm not sure whether it has > simply been overlooked but the number of people get_maintainer.pl was > rather small and seemed a little random so I added Linus and Christoph, > two people I know that do look at VFS stuff at least from time to time, > although they weren't listed by get_maintainer.pl. I hope that's ok. > > This little series > - unifies the definition of constants in statfs.h and fs.h > *Note, that Andreas has expressed doubts whether this unification is > useful. Please see https://lkml.org/lkml/2018/4/13/571 . I still think > it is but I'm happy to drop these two patches if others agree.* > - extends statfs to handle mount propagation. This will let userspace > easily query a given mountpoint for MS_UNBINDABLE, MS_SHARED, > MS_PRIVATE and MS_SLAVE without always having to do costly parsing of > /proc//mountinfo. > To this end the flags: > - ST_UNBINDABLE > - ST_SHARED > - ST_PRIVATE > - ST_SLAVE > are added. They have the same value as their MS_* counterparts. How about some rationale for that in the first place? statfs() looks like a bad match for that - not to mention anything else, there's no way to get anything beyond "it is a peer of something", not even "do these two get propagation between them". What would be using that, what would the userland side of users look like, etc... And in any case linux-api should've been Cc'd. I'm not saying that this (or something similar) would be an inherently bad idea, but the question "why this way?" deserves a bit more than "parsing is costly"...