Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2340302ybz; Thu, 23 Apr 2020 16:20:14 -0700 (PDT) X-Google-Smtp-Source: APiQypLLwD0EIGXWR5Lj2ufYNtjAfHtrymEx+nBJwVev86Z6OzMvCgJbgiS3enkXkcuaEhX+an5Y X-Received: by 2002:a05:6402:1fc:: with SMTP id i28mr4874116edy.18.1587684014279; Thu, 23 Apr 2020 16:20:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587684014; cv=none; d=google.com; s=arc-20160816; b=cFwWenQndDw0/24fXwFXlnj7CXyAN5qHjvlim8Sj6KJBYRKn5NHgLWGcQ+1M13hOnF 0c83CBgdEiU8pyRDv0wG7Dz3vjtSG6hAfvoXxMw7qFcBT2jMGfa6UkqylLc+zjIPLFI9 cvOg0ckQtqj1v8pI2EkasvPcUlOiW2yMI0Ej1eV3kzFByOx8bTD59WtVwIxj+wD9Ih8s ccx2njnI5F5qTNOFNmXNUn0NGZCXUgobi20nYTa3XApEpW3Y8rzWBDVtdbh9WxVkBRG9 WvMcy9KkSxyrSf/oB32wD5Pkzrny4ILWFOyRQ/siQ4jJeGSUdc1pReNGwe/A3vZQSZ9/ Qq2g== 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=Osiu4f6Hb17SEkZCPyYGq+HeOdngdj8NJseOSSNj9Yc=; b=QNFm3lgibGjKpMlKFiMHePk0qi0axCiiblIyYZowZYviPggqVG41Tx+St53cD3aQ3F mxV43A0LymWyhEx6zi7MpbsdQvbLYHqZexm0aoJbyikhgTiToBFDLVgd0CxNztPBwlYJ 8K6KodZqHO7fCJDSXBE0CC/fOMNdRLcWwTfx/LzRMB4yM+Or4hMHVMQWXRr4Jk85FYMY PR0A/FMh9djNURDfjXqmUukmM7qLiK7uQKDxo8z67t/q4/RXPXqTuMFXzHANK89hEKHm Uavo+t+CCAOnv1nOL/J6T27xj+nzTIvo0US/IUL42RCb+mNo+XX19+C5N5TC7MRQfBHS zlnw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s18si2028598ejr.449.2020.04.23.16.19.51; Thu, 23 Apr 2020 16:20:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729007AbgDWXRW (ORCPT + 99 others); Thu, 23 Apr 2020 19:17:22 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49330 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728327AbgDWXGm (ORCPT ); Thu, 23 Apr 2020 19:06:42 -0400 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 1jRkvS-0004hY-5i; Fri, 24 Apr 2020 00:06:34 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvP-00E6o4-Uz; Fri, 24 Apr 2020 00:06:31 +0100 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, Denis Kirjanov , "Josef Bacik" , "David Sterba" Date: Fri, 24 Apr 2020 00:05:40 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 113/245] btrfs: do not call synchronize_srcu() in inode_tree_del 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.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Josef Bacik commit f72ff01df9cf5db25c76674cac16605992d15467 upstream. Testing with the new fsstress uncovered a pretty nasty deadlock with lookup and snapshot deletion. Process A unlink -> final iput -> inode_tree_del -> synchronize_srcu(subvol_srcu) Process B btrfs_lookup <- srcu_read_lock() acquired here -> btrfs_iget -> find inode that has I_FREEING set -> __wait_on_freeing_inode() We're holding the srcu_read_lock() while doing the iget in order to make sure our fs root doesn't go away, and then we are waiting for the inode to finish freeing. However because the free'ing process is doing a synchronize_srcu() we deadlock. Fix this by dropping the synchronize_srcu() in inode_tree_del(). We don't need people to stop accessing the fs root at this point, we're only adding our empty root to the dead roots list. A larger much more invasive fix is forthcoming to address how we deal with fs roots, but this fixes the immediate problem. Fixes: 76dda93c6ae2 ("Btrfs: add snapshot/subvolume destroy ioctl") Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba [bwh: Backported to 3.16: No fs_info variable was used here] Signed-off-by: Ben Hutchings --- --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -5140,7 +5140,6 @@ static void inode_tree_del(struct inode spin_unlock(&root->inode_lock); if (empty && btrfs_root_refs(&root->root_item) == 0) { - synchronize_srcu(&root->fs_info->subvol_srcu); spin_lock(&root->inode_lock); empty = RB_EMPTY_ROOT(&root->inode_tree); spin_unlock(&root->inode_lock);