Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp258315imm; Thu, 31 May 2018 23:44:25 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLSZlXa6Cgxm+gBcoqPTmRzOkDi5dTEHPTqKuZO5vmw86gWdtwZRuE6drL4z4YVgnY+jyxY X-Received: by 2002:a17:902:6181:: with SMTP id u1-v6mr9821697plj.369.1527835464960; Thu, 31 May 2018 23:44:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527835464; cv=none; d=google.com; s=arc-20160816; b=mQD2MH59lSri7vkcIpjIyENND6uUcoTwqFQ+QZL+XJpcLjlrFaqZ+FsyJ8/tVlaAPE OIQg/n1dJw9IiR8ZdqzXZKrovOO7LY2//Lmtc4cdO5I1+LHjlsfpIXjO3ax7JWPHXXA4 q+Qw6pHUdk01LR71AszuYUvsk0P20HceO8ltrhs18uur63yLbjRtPtqAlnMOhF6QzLJE zEb//XTw7WCYJLOVE57q1XaLAtaVY3ZfAlcbwEST/nEG2OKUs4CoKVgP3+eOvDgyRxcP hMpj22A7Wlqxn4DheuFFpB6KhtM6wme8KM298mhowB+WXXa3ZRhuBBVOI88Or7/HsO0c BxPQ== 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=d9HJN8yH68w8H8XK4jvjKU+ZIh3FnP4QgFdjfeM0ODs=; b=N5Oh/Wt7dg9XuuJLWNTGeGgoHJtTK1djqXuesjjF0AaQ6Z53eZBw9z4MHYmNrMDxgj FsjAZP68+PonsGqW52lecSpY4PMa0jTqQX+Znj6rpwXI5J4JsFwT2dgw5/79k6MhLdlw 1WImQFMVGmg9mixT86L5+Ydrhu/s0CAPYDhI2ZXNEEXdvdCFy0fZqsCjBiLNy5KXug7n TWIimXkDnJiHacQtFfTmHKUcd0+0d+40/UNu1ZyGwNqsPNMDXYWZszCBsVUSnrSAFW0Y wfBL/iItP6z5MBWw6NdqLiKFVySYrAg0/aFEvZT0tJ5w8mkI/Fc7wNtUbM+gdT8wxzXa 3fGg== 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 a3-v6si30361203pgq.652.2018.05.31.23.43.57; Thu, 31 May 2018 23:44:24 -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 S1750983AbeFAGje (ORCPT + 99 others); Fri, 1 Jun 2018 02:39:34 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:34074 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbeFAGjc (ORCPT ); Fri, 1 Jun 2018 02:39:32 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fOdii-0005tO-M1; Fri, 01 Jun 2018 06:39:28 +0000 Date: Fri, 1 Jun 2018 07:39:28 +0100 From: Al Viro To: Christoph Hellwig Cc: David Howells , 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: <20180601063928.GS30522@ZenIV.linux.org.uk> References: <152720672288.9073.9868393448836301272.stgit@warthog.procyon.org.uk> <152720691829.9073.10564431140980997005.stgit@warthog.procyon.org.uk> <20180601062654.GA32397@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180601062654.GA32397@infradead.org> 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 Thu, May 31, 2018 at 11:26:54PM -0700, Christoph Hellwig wrote: > On Fri, May 25, 2018 at 01:08:38AM +0100, David Howells wrote: > > Make it possible to clone a mount tree with a new pair of open flags that > > are used in conjunction with O_PATH: > > > > (1) O_CLONE_MOUNT - Clone the mount or mount tree at the path. > > > > (2) O_NON_RECURSIVE - Don't clone recursively. > > Err. I don't think we should use up two O_* flags for something > only useful for your new mount API. Don't we have a better place > to for these flags? > > 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.