linux-kernel - [PATCH 3.10 001/268] Revert "Btrfs: don't delay inode ref updates during log, replay"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1497897167-14556-2-git-send-email-w@1wt.eu>
Date:   Mon, 19 Jun 2017 20:28:20 +0200
From:   Willy Tarreau <w@....eu>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        linux@...ck-us.net
Cc:     Jeff Mahoney <jeffm@...e.com>, Willy Tarreau <w@....eu>
Subject: [PATCH 3.10 001/268] Revert "Btrfs: don't delay inode ref updates during log, replay"

From: Jeff Mahoney <jeffm@...e.com>

commit 081fafddc3ff1e86e36024b0177c08e340b19a12 upstream.

This reverts commit 644d10716875b24388680925d6c7502420987bfe, upstream
commit 6f8960541b1eb6054a642da48daae2320fddba93.

The original patch for mainline, 6f8960541b1 (Btrfs: don't delay
inode ref updates during log replay) lists 1d52c78afbb (Btrfs: try
not to ENOSPC on log replay) as the only pre-3.18 dependency, but it
also depends on 67de11769bd (Btrfs: introduce the delayed inode ref
deletion for the single link inode), which was introduced in 3.14
and isn't in 3.12.y.

The -stable commit added the check to btrfs_delayed_update_inode,
which may look similar to btrfs_delayed_delete_inode_ref, but it's
only superficial.  The tops of both functions handle typical
delayed node boilerplate.  The upshot is that the patch is harmless
since the caller already checks to see if we're doing log recovery,
so we're not breaking anything.  It should be reverted because it
makes it appear as if this issue was fixed for users who did
backport 67de11769bd, when it is not.

Signed-off-by: Jeff Mahoney <jeffm@...e.com>
Signed-off-by: Willy Tarreau <w@....eu>
---
 fs/btrfs/delayed-inode.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 019fc5a..f26f38c 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1843,14 +1843,6 @@ int btrfs_delayed_update_inode(struct btrfs_trans_handle *trans,
 	struct btrfs_delayed_node *delayed_node;
 	int ret = 0;

-	/*
-	 * we don't do delayed inode updates during log recovery because it
-	 * leads to enospc problems.  This means we also can't do
-	 * delayed inode refs
-	 */
-	if (BTRFS_I(inode)->root->fs_info->log_root_recovering)
-		return -EAGAIN;
-
 	delayed_node = btrfs_get_or_create_delayed_node(inode);
 	if (IS_ERR(delayed_node))
 		return PTR_ERR(delayed_node);
-- 
2.8.0.rc2.1.gbe9624a