From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH v16 06/12] namei: LOOKUP_NO_XDEV: block mountpoint crossing Date: Sat, 16 Nov 2019 01:01:44 +0000 Message-ID: <20191116010144.GY26530@ZenIV.linux.org.uk> References: <20191116002802.6663-1-cyphar@cyphar.com> <20191116002802.6663-7-cyphar@cyphar.com> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20191116002802.6663-7-cyphar@cyphar.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Aleksa Sarai Cc: Song Liu , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Rasmus Villemoes , Alexei Starovoitov , linux-kernel@vger.kernel.org, David Howells , linux-kselftest@vger.kernel.org, sparclinux@vger.kernel.org, containers@lists.linux-foundation.org, Christian Brauner , linux-api@vger.kernel.org, Shuah Khan , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Tycho Andersen , Daniel Borkmann , Jiri Olsa , Alexander Shishkin , Ingo Molnar , linux-arm-kernel@lists.infradead.org, Yonghong Song , linux-mips@vger.kernel.org, Andrii Nakryiko , bpf@vger.kernel.org, l On Sat, Nov 16, 2019 at 11:27:56AM +1100, Aleksa Sarai wrote: > @@ -1383,6 +1398,8 @@ static int follow_dotdot_rcu(struct nameidata *nd) > return -ECHILD; > if (&mparent->mnt == nd->path.mnt) > break; > + if (unlikely(nd->flags & LOOKUP_NO_XDEV)) > + return -EXDEV; > /* we know that mountpoint was pinned */ > nd->path.dentry = mountpoint; > nd->path.mnt = &mparent->mnt; > @@ -1397,6 +1414,8 @@ static int follow_dotdot_rcu(struct nameidata *nd) > return -ECHILD; > if (!mounted) > break; > + if (unlikely(nd->flags & LOOKUP_NO_XDEV)) > + return -EXDEV; > nd->path.mnt = &mounted->mnt; > nd->path.dentry = mounted->mnt.mnt_root; > inode = nd->path.dentry->d_inode; I really don't think we should return hard errors from that function. Let the caller redo it in refwalk mode. It's not the fast path, especially for this kind of errors. Matter of fact, I'm not sure about -ENOENT returned in another failure case there - it's probably OK, but again, -ECHILD would be just as good.