Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1274697imm; Fri, 1 Jun 2018 20:10:11 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLmlevSrpNzFITVwIKlePatopQLTnuYLmBTlBnXTWPPFiqeyk2dYNlRXr4H8vpqABSzwWjY X-Received: by 2002:a62:9f16:: with SMTP id g22-v6mr7622572pfe.207.1527909011063; Fri, 01 Jun 2018 20:10:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527909011; cv=none; d=google.com; s=arc-20160816; b=xK/wDw3HzEGvcvAzjTOx6yf583Qkk8D0P9Hjmt8aWxic/xC8bpu3wMFwNy5MTDQ0R7 tb0MWGVx5E/ijpfi0E/1qlWPokmHuy4008W7YL1yawE37sHwzKRV3IyPHsPu21PVu8i1 XwPsXowJPAbq4ZM6+9GmfReNgreAfx4ZAheV6ZJD0ZF6harVxxrHKTy0nsEz+AKx+uNq IhPEPjaJLYcmmFH4ESRF85UwcV1+hMdTjofh7Sgp8PmB12kKzeDOfe5yJimpZ8iTOyhQ 6Re5WMrp2J1c1EjhpAaahyAXD871GLg8oj8460EpAWUx+UPl+WtStGk0PfRSZJZ/pHBP h9Pg== 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=GXNZGKGpSy7q0fJZZwMoJRE8qRkk7WzBswWp+/M36Es=; b=mG5Hj0IEI/0KXDO0YnbFv+HYK0zkuEg9yqN+jiF4HNpQSLyegyADNK6rmSSHLN/yNO iTdCclIVRR5nCBLbzA2jsQAAAvbsTLSqRtB09hdTRGRM1YMkMNgAgMP16aIIPEljGgHz lchgalyK+QaWyMU8wroUlRx6RkwHYuq3ThnoBoSTlojcqvp8U1DcUX7Sm8lkK5YwLQkA uU7Aq29jIWkpjPEW+dkBcBbHMO+e+F9HE/aNr1UHmHWQ0TGeCXGCe36Ahlh5nyn8sRrl aCvBtrsCSY0Djxpy0ih0EIZa8qxbyAPs0NUpOUFNcPwuakN4bGutxxSPM2upTPGPEri1 HDtA== 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 l81-v6si42397438pfj.127.2018.06.01.20.09.56; Fri, 01 Jun 2018 20:10:11 -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 S1751291AbeFBDJ3 (ORCPT + 99 others); Fri, 1 Jun 2018 23:09:29 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:34356 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750736AbeFBDJ1 (ORCPT ); Fri, 1 Jun 2018 23:09:27 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fOwuo-0002Of-Gs; Sat, 02 Jun 2018 03:09:14 +0000 Date: Sat, 2 Jun 2018 04:09:14 +0100 From: Al Viro To: David Howells Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH 30/32] vfs: Allow cloning of a mount tree with open(O_PATH|O_CLONE_MOUNT) [ver #8] Message-ID: <20180602030913.GU30522@ZenIV.linux.org.uk> References: <20180601063928.GS30522@ZenIV.linux.org.uk> <152720672288.9073.9868393448836301272.stgit@warthog.procyon.org.uk> <152720691829.9073.10564431140980997005.stgit@warthog.procyon.org.uk> <20180601062654.GA32397@infradead.org> <7067.1527841663@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7067.1527841663@warthog.procyon.org.uk> 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 Fri, Jun 01, 2018 at 09:27:43AM +0100, David Howells wrote: > Al Viro wrote: > > > > Instead of overloading this on open having a specific syscalls just > > > seems like a much saner idea. > > > > It's not just mount API; these can be used independently of that. > > Think of the uses where you pass those to ...at() and you'll see > > a bunch of applications of that thing. > > I kind of agree with Christoph on this point. Yes, you can use the resultant > fd for other things, but that doesn't mean it has to be obtained initially > through open() or openat() rather than, say, a new pick_mount() syscall. > > Further, having more parameters available gives us the opportunity to change > the settings on any mounts we create at the point of creation. open_subtree(int dirfd, const char *pathname, int flags), then? How would flags be interpreted? What I see mapping at that thing is * equivalent of O_PATH open * clone subtree, O_PATH open root * clone one mount, O_PATH open root and apparently you want to add (orthogonal to that) * make shared/slave/private/unbindable * ditto with recursion? * same for nodev/nosuid/noexec/noatime/nodiratime/relatime/ro/? as well as usual AT_... flags (empty path, follow) Choose the encoding...