From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C09CC742D7 for ; Sat, 13 Jul 2019 02:42:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1FF1D208E4 for ; Sat, 13 Jul 2019 02:42:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727431AbfGMCmV (ORCPT ); Fri, 12 Jul 2019 22:42:21 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:48010 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727338AbfGMCmU (ORCPT ); Fri, 12 Jul 2019 22:42:20 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1hm7yz-0001A3-CY; Sat, 13 Jul 2019 02:41:53 +0000 Date: Sat, 13 Jul 2019 03:41:53 +0100 From: Al Viro To: Aleksa Sarai Cc: Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , David Howells , Shuah Khan , Shuah Khan , Christian Brauner , David Drysdale , Andy Lutomirski , Linus Torvalds , Eric Biederman , Andrew Morton , Alexei Starovoitov , Kees Cook , Jann Horn , Tycho Andersen , Chanho Min , Oleg Nesterov , Aleksa Sarai , containers@lists.linux-foundation.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, sparclinux@vger.kernel.org Subject: Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags Message-ID: <20190713024153.GA3817@ZenIV.linux.org.uk> References: <20190706145737.5299-1-cyphar@cyphar.com> <20190706145737.5299-6-cyphar@cyphar.com> <20190712043341.GI17978@ZenIV.linux.org.uk> <20190712105745.nruaftgeat6irhzr@yavin> <20190712123924.GK17978@ZenIV.linux.org.uk> <20190712125552.GL17978@ZenIV.linux.org.uk> <20190712132553.GN17978@ZenIV.linux.org.uk> <20190712150026.GO17978@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190712150026.GO17978@ZenIV.linux.org.uk> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote: > On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote: > > > if (flags & LOOKUP_BENEATH) { > > nd->root = nd->path; > > if (!(flags & LOOKUP_RCU)) > > path_get(&nd->root); > > else > > nd->root_seq = nd->seq; > > BTW, this assignment is needed for LOOKUP_RCU case. Without it > you are pretty much guaranteed that lazy pathwalk will fail, > when it comes to complete_walk(). > > Speaking of which, what would happen if LOOKUP_ROOT/LOOKUP_BENEATH > combination would someday get passed? I don't understand what's going on with ->r_seq in there - your call of path_is_under() is after having (re-)sampled rename_lock, but if that was the only .. in there, who's going to recheck the value? For that matter, what's to guarantee that the thing won't get moved just as you are returning from handle_dots()? IOW, what does LOOKUP_IN_ROOT guarantee for caller (openat2())?