Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3331596imu; Sun, 11 Nov 2018 12:32:52 -0800 (PST) X-Google-Smtp-Source: AJdET5eG0H74msVbI4AM6SbCf7Z+XRZIxhy3ju+L3ITdV7el/kkRQ5QWXGKNwYGp33PD37GLYO3j X-Received: by 2002:a17:902:8f8f:: with SMTP id z15-v6mr17439563plo.257.1541968372431; Sun, 11 Nov 2018 12:32:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541968372; cv=none; d=google.com; s=arc-20160816; b=oaBoyKp3uF+Uhc2qIRPq+Ah0yhjILdVOm9MoJQob2ZVpHHF4QtokbMvPxAdEnUYa06 oi/vqdw56IzlIxn/f6s/3oCBBVVUrO4dPpkYKzu1/PONZAY7qb6k/Bh401r3r1aoJwUo oK4cSugFY1ovu0ghzqP4awqYps2dJcRZegVBOY39i+J1nQopUkQUvsLxG+5+AbEXoRHK g6pCWOJCFX+AXEDmxYamjO9ZoNFTAeVi6mspelLcHTGpOdgYMZnqBhKM0BJRxmLyJlZo 6/2WfeKysYZvT6+7KDd4jW2jwcbnjkT6I8D5ANOwTCJCZrP+eue/BsPbQWajRSpiIV0G bc6w== 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=j9dOCDXzDSOeR6Jbk5VwmRzoFz24OVrzP2MkeKyFZYQ=; b=tdkkIOUF40Onng7oGqz1mSilGTArYaBJ0dbO+jVnwRmKR3QBog2ZujAbcZc0Qigjrg tUpwGtndJSd1bOSm1iNIaJrTpGZNMkMSC5/EWQFhp1lY1QsStfupBCxP+wE2tMjB8QFV TBQKnKLSdR5wT2nSVtWphYGjd2iZ2ISBQPwc22NUZcacfqixpAH6GvwUtkJlqsQarobZ FWy6VEvScpVS1Jq94gk0vwFy4mnIhTlaD1jm+VkuezhB7Gh2drfjb43reXgn+3/u+d7h Ub68LBIuCFqSTl9Uz4IIkukaWxMUYK1cxmfu6X3y4hnWDQiaKNK66dddQbs+aqRlKlj4 oZGg== 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 v3si14770706pgh.305.2018.11.11.12.32.37; Sun, 11 Nov 2018 12:32:52 -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 S1730343AbeKLFsR (ORCPT + 99 others); Mon, 12 Nov 2018 00:48:17 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50114 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730255AbeKLFsQ (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-0000l6-3k; Sun, 11 Nov 2018 19:58:46 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsZ-0001pq-Dl; 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" , "Dae R. Jeong" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 320/366] make sure that __dentry_kill() always invalidates d_seq, unhashed or not 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 4c0d7cd5c8416b1ef41534d19163cb07ffaa03ab upstream. RCU pathwalk relies upon the assumption that anything that changes ->d_inode of a dentry will invalidate its ->d_seq. That's almost true - the one exception is that the final dput() of already unhashed dentry does *not* touch ->d_seq at all. Unhashing does, though, so for anything we'd found by RCU dcache lookup we are fine. Unfortunately, we can *start* with an unhashed dentry or jump into it. We could try and be careful in the (few) places where that could happen. Or we could just make the final dput() invalidate the damn thing, unhashed or not. The latter is much simpler and easier to backport, so let's do it that way. Reported-by: "Dae R. Jeong" Signed-off-by: Al Viro Signed-off-by: Ben Hutchings --- fs/dcache.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -340,14 +340,11 @@ static void dentry_unlink_inode(struct d __releases(dentry->d_inode->i_lock) { struct inode *inode = dentry->d_inode; - bool hashed = !d_unhashed(dentry); - if (hashed) - raw_write_seqcount_begin(&dentry->d_seq); + raw_write_seqcount_begin(&dentry->d_seq); __d_clear_type_and_inode(dentry); hlist_del_init(&dentry->d_u.d_alias); - if (hashed) - raw_write_seqcount_end(&dentry->d_seq); + raw_write_seqcount_end(&dentry->d_seq); spin_unlock(&dentry->d_lock); spin_unlock(&inode->i_lock); if (!inode->i_nlink)