Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2339760ybz; Thu, 23 Apr 2020 16:19:31 -0700 (PDT) X-Google-Smtp-Source: APiQypJB8zxx91ofBVPFtD7EWU6Df84bWCmLH/zkjZykYyqDMllPBLtDUXDcvqNs4JXpK/gU8/9z X-Received: by 2002:a17:906:6050:: with SMTP id p16mr4930637ejj.179.1587683971087; Thu, 23 Apr 2020 16:19:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683971; cv=none; d=google.com; s=arc-20160816; b=R8ErHIOW1Eu4DNR6D6xtZiP9C7VeW+XebSj2kWLLeqgIROWoPHR1noqPxplYGwTAcO 7oNFeeRgJ2/yAYBQ30lVlDJBvRYxvXlgLdY5XKDMmB6Gcl23Lgot9T01EqX+oWNtp5io 8kwJFCvMLIt6O3wxNO7308qAFBHXcf1fxb7MZnKs8BjC3RqLtGiQWvJ0HkzThRmdaqmp IfGRIsomqrZAEkZXtI2TzfivQiGjKxNrJsAA5SjIjvwE8UVSTKqRzPAjsEJjRPvJM4wK gbL6k2nzH0pxKC8tZ904ZvOxgOMVTIzUTY2LNS0BGERRnWx9vxpxooF73xCWAF1dP/bE 4aCg== 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=ti/2bQVJcLxznthR5H/po5pwxDOYGYvYFkap265JKmc=; b=pXmgixxFpLwdurMBERh4f/c7QusVbG+xcFZf+8rc2WUn6/vjIxl7JCi/96WxNlXTH9 CWmLuDlz9oIYJfg7qhH1BsfazZiOYHbzGxpGv6F83g4kCsJr7c9jKi1w7nBkQ50UfNEk X5eemWgeCiEEFbeK7O1GkZIteXkqgd4xDT15DQY4z9uUzm8wrHNHBCNqxMa8QOGI+5d5 U84k7NljlbTWKg8xzSGjZJb2xbtf94rGmNFoMcJncOU+azQG9t+lCdHGW5rvXC26XFct SkTGbb83YWY7Z7hxG+JKyy+DzHd2sx9lfdZk411uOfeHfM98B9s1qEW0YRBiG5VMQmPK k+7g== 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 a16si2499088edn.579.2020.04.23.16.19.07; Thu, 23 Apr 2020 16:19:31 -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 S1729266AbgDWXRO (ORCPT + 99 others); Thu, 23 Apr 2020 19:17:14 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49338 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728331AbgDWXGm (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-0004hp-Fi; Fri, 24 Apr 2020 00:06:34 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvQ-00E6oO-C6; Fri, 24 Apr 2020 00:06:32 +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 , "Filipe Manana" , "Josef Bacik" , "David Sterba" Date: Fri, 24 Apr 2020 00:05:44 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 117/245] btrfs: skip log replay on orphaned roots 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 9bc574de590510eff899c3ca8dbaf013566b5efe upstream. My fsstress modifications coupled with generic/475 uncovered a failure to mount and replay the log if we hit a orphaned root. We do not want to replay the log for an orphan root, but it's completely legitimate to have an orphaned root with a log attached. Fix this by simply skipping replaying the log. We still need to pin it's root node so that we do not overwrite it while replaying other logs, as we re-read the log root at every stage of the replay. Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba [bwh: Backported to 3.16: - Pass fs_info->extent_root, instead of fs_info, as first argument to btrfs_pin_extent_for_log_replay() - Adjust context] Signed-off-by: Ben Hutchings --- --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -4583,9 +4583,29 @@ again: wc.replay_dest = btrfs_read_fs_root_no_name(fs_info, &tmp_key); if (IS_ERR(wc.replay_dest)) { ret = PTR_ERR(wc.replay_dest); + + /* + * We didn't find the subvol, likely because it was + * deleted. This is ok, simply skip this log and go to + * the next one. + * + * We need to exclude the root because we can't have + * other log replays overwriting this log as we'll read + * it back in a few more times. This will keep our + * block from being modified, and we'll just bail for + * each subsequent pass. + */ + if (ret == -ENOENT) + ret = btrfs_pin_extent_for_log_replay( + fs_info->extent_root, + log->node->start, + log->node->len); free_extent_buffer(log->node); free_extent_buffer(log->commit_root); kfree(log); + + if (!ret) + goto next; btrfs_error(fs_info, ret, "Couldn't read target root " "for tree log recovery."); goto error; @@ -4600,7 +4620,6 @@ again: path); } - key.offset = found_key.offset - 1; wc.replay_dest->log_root = NULL; free_extent_buffer(log->node); free_extent_buffer(log->commit_root); @@ -4608,9 +4627,10 @@ again: if (ret) goto error; - +next: if (found_key.offset == 0) break; + key.offset = found_key.offset - 1; } btrfs_release_path(path);