Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1125204ybl; Sat, 18 Jan 2020 19:23:46 -0800 (PST) X-Google-Smtp-Source: APXvYqxYY8ZDpi61F6ycx/NA6yXYMXYKc0Whi9+whJaenyjgusXzpa5F10vXNXtNACmu68nPJCmW X-Received: by 2002:aca:4d58:: with SMTP id a85mr8650461oib.35.1579404226340; Sat, 18 Jan 2020 19:23:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579404226; cv=none; d=google.com; s=arc-20160816; b=YxVbGbHj0pq08x2ruJfATc1zYmkYOOycTYxK5FLaYwJXCZFauM93xEq0cA6I0aM5D+ hdIGfM/pclWjA9t30IN+pAnQY/ik4K/qYIfWtMgE0lIMoKNGg+xBXflvgFQal2kGNNS8 Y0WVnbAtOxXU0m6kSBP01e8rPBXG1R55eDxmDTV+WD/DrGYnGwVhziQLtYIKsi2PjJFa 0fE+vEnvvBlux/0pBwR0xE9O8GsDI6AejqGEBNbplOI22S8gtWKrEWsxunp7ipGskhdD An8s4b98LI8iDSM+pUSB5iUBERnXCXV4f0JacbqglpCL2pKk96zhC9KSE1tn1v/Y7l0u 8dig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=JOHXSRu94iIe/oiKr2dibUxxMV4NdyEGYdBMigDrVuA=; b=qc7BVFrjE7f0A7stFTD41AII67l2wnWYC3opW+pCPHH3itmVzH8zA3zZQ+9G/Jcen3 IeW0tlQM19cAwTDy8A+VRdCb+1DfrBYkmqaajZTJ2HEMxT/v+kjxkoUE3gGq3fgJ4Zw5 QgJ/64Y+QirNAhmP60/1p6woIWhjtoVxOt0mRxI7lwdY+coa/WJowq0n6OcvViaRqjvn n1z69m7KOssLD0CSUNU0lsiAmZYa+1Yf+jlDPL9z1I+hxo0catLmJMuUh08csZxIpkUO CjjGRT3keZB3jqt6PcvQDqJbSDAmQct2o3roSdIpsOxUv3/3ZOGXiIEMunNy3q1Qs4wf iR7w== 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 w23si17220449oti.39.2020.01.18.19.23.34; Sat, 18 Jan 2020 19:23:46 -0800 (PST) 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 S1728733AbgASDVU (ORCPT + 99 others); Sat, 18 Jan 2020 22:21:20 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:56802 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725906AbgASDVU (ORCPT ); Sat, 18 Jan 2020 22:21:20 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1it18s-00BFaX-7N; Sun, 19 Jan 2020 03:20:51 +0000 From: Al Viro To: linux-fsdevel@vger.kernel.org Cc: Linus Torvalds , linux-kernel@vger.kernel.org, Aleksa Sarai , David Howells , Eric Biederman , Christian Brauner , Al Viro Subject: [PATCH 11/17] lookup_fast(): consolidate the RCU success case Date: Sun, 19 Jan 2020 03:17:23 +0000 Message-Id: <20200119031738.2681033-11-viro@ZenIV.linux.org.uk> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200119031738.2681033-1-viro@ZenIV.linux.org.uk> References: <20200119031423.GV8904@ZenIV.linux.org.uk> <20200119031738.2681033-1-viro@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Al Viro 1) in case of __follow_mount_rcu() failure, lookup_fast() proceeds to call unlazy_child() and, should it succeed, handle_mounts(). Note that we have status > 0 (or we wouldn't be calling __follow_mount_rcu() at all), so all stuff conditional upon non-positive status won't be even touched. Consolidate just that sequence after the call of __follow_mount_rcu(). 2) calling d_is_negative() and keeping its result is pointless - we either don't get past checking ->d_seq (and don't use the results of d_is_negative() at all), or we are guaranteed that ->d_inode and type bits of ->d_flags had been consistent at the time of d_is_negative() call. IOW, we could only get to the use of its result if it's equal to !inode. The same ->d_seq check guarantees that after that point this CPU won't observe ->d_flags values older than ->d_inode update. So 'negative' variable is completely pointless these days. Signed-off-by: Al Viro --- fs/namei.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index f95c072bad03..2e416bd8ee26 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1538,7 +1538,6 @@ static int lookup_fast(struct nameidata *nd, */ if (nd->flags & LOOKUP_RCU) { unsigned seq; - bool negative; dentry = __d_lookup_rcu(parent, &nd->last, &seq); if (unlikely(!dentry)) { if (unlazy_walk(nd)) @@ -1551,7 +1550,6 @@ static int lookup_fast(struct nameidata *nd, * the dentry name information from lookup. */ *inode = d_backing_inode(dentry); - negative = d_is_negative(dentry); if (unlikely(read_seqcount_retry(&dentry->d_seq, seq))) return -ECHILD; @@ -1572,12 +1570,15 @@ static int lookup_fast(struct nameidata *nd, * Note: do negative dentry check after revalidation in * case that drops it. */ - if (unlikely(negative)) + if (unlikely(!inode)) return -ENOENT; path->mnt = mnt; path->dentry = dentry; if (likely(__follow_mount_rcu(nd, path, inode, seqp))) return 1; + if (unlazy_child(nd, dentry, seq)) + return -ECHILD; + return handle_mounts(nd, dentry, path, inode, seqp); } if (unlazy_child(nd, dentry, seq)) return -ECHILD; -- 2.20.1