Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3332470imu; Sun, 11 Nov 2018 12:34:01 -0800 (PST) X-Google-Smtp-Source: AJdET5df43CvdAqKZHRIGHY3P/z+K8Z+i0G5EieB2beCbx6wN3zr9A9pYwe26EKyBqJz5TYV+RjR X-Received: by 2002:a63:5ec6:: with SMTP id s189mr14579500pgb.357.1541968441795; Sun, 11 Nov 2018 12:34:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541968441; cv=none; d=google.com; s=arc-20160816; b=Wpu3Q481R+rovMioMIxpqw8nGx1qff83GcV+Cm5zW8/1ben4mmW38oDaFKqDTe/o6h uONOg8yMxU3iqBGpt/03wa/wAylTa355O4jKhDElaWUzNmCOhDcQ2lLq/+VETB59pY/9 pSzK4QH/D2WSf9hNbVzW9386DJK6/QGrqRZM3ICAAFUuz/svRwArpY6y9w2WWtlRyVDM xLdWjopicFh3jE9GOkSZXbLpywMWGDV49OL9g+K3rVFSrF8OdsFKNgWkgY9BPqu9e5UU zAOJeT0SXpW2slLH1B6n226+mviWpIMZmLLbmxJStJDFfBH/A/ZaL0xuLB3a2tDZ49B1 W8GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=lz8F856syQI9iBSsjUS9MzCr0X+2ZV4td5STQ7MDMcA=; b=mqu9UrPoHPeVWPEKueDjyVqAba8f0OXyz7w5RW5XErfggPGym8EKVeb4ZbPfgNh+Xz CwKtt1bgXwv5WO0q58aQpL0iMsYx+hSagSTuSqVhOVs7gYx5hYYJCKLWmrf+WSY2gXL9 CuTJxjZNrt71B31PLYWcWscuw1qAuiYooC1M7oF/OINsUUQnm8Ja0evMrz53wBpQZsle DtTyshy2pmhnoZOl7Lw5mLGWf9Cae9urmDnpio5qaNe31meQuvNw69MzMCgL/1dgFW4c +aP+6l5Z9IsQzDLjW1UwdLjhWTjUBNHj1zmjIqDJXj4jUjqZWbtQpXXhhRradiRr8TjA Uxhw== 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 s14-v6si4777736plr.93.2018.11.11.12.33.46; Sun, 11 Nov 2018 12:34:01 -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 S1730510AbeKLGW4 (ORCPT + 99 others); Mon, 12 Nov 2018 01:22:56 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50142 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730262AbeKLFsQ (ORCPT ); Mon, 12 Nov 2018 00:48:16 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvsc-0000oU-Dt; Sun, 11 Nov 2018 19:58:46 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsZ-0001p7-4i; Sun, 11 Nov 2018 19:58:43 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Al Viro" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 311/366] root dentries need RCU-delayed freeing In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Al Viro commit 90bad5e05bcdb0308cfa3d3a60f5c0b9c8e2efb3 upstream. Since mountpoint crossing can happen without leaving lazy mode, root dentries do need the same protection against having their memory freed without RCU delay as everything else in the tree. It's partially hidden by RCU delay between detaching from the mount tree and dropping the vfsmount reference, but the starting point of pathwalk can be on an already detached mount, in which case umount-caused RCU delay has already passed by the time the lazy pathwalk grabs rcu_read_lock(). If the starting point happens to be at the root of that vfsmount *and* that vfsmount covers the entire filesystem, we get trouble. Fixes: 48a066e72d97 ("RCU'd vsfmounts") Signed-off-by: Al Viro Signed-off-by: Ben Hutchings --- fs/dcache.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1812,10 +1812,12 @@ struct dentry *d_make_root(struct inode static const struct qstr name = QSTR_INIT("/", 1); res = __d_alloc(root_inode->i_sb, &name); - if (res) + if (res) { + res->d_flags |= DCACHE_RCUACCESS; d_instantiate(res, root_inode); - else + } else { iput(root_inode); + } } return res; }