Btrfs: fix unexpected -EEXIST when creating new inode

"Linux Kernel Mailing List" <[email protected]> Fri, 16 Feb 2018 17:44:22 +0000 (UTC)
Newsgroups gmane.linux.kernel.commits.head
Message-ID <[email protected]>
Web:        https://git.kernel.org/torvalds/c/900c9981680067573671ecc5cbfa7c5770be3a40
Commit:     900c9981680067573671ecc5cbfa7c5770be3a40
Parent:     1a932ef4e47984dee227834667b5ff5a334e4805
Refname:    refs/heads/master
Author:     Liu Bo <[email protected]>
AuthorDate: Thu Jan 25 11:02:56 2018 -0700
Committer:  David Sterba <[email protected]>
CommitDate: Fri Feb 2 16:24:53 2018 +0100

    Btrfs: fix unexpected -EEXIST when creating new inode
    
    The highest objectid, which is assigned to new inode, is decided at
    the time of initializing fs roots.  However, in cases where log replay
    gets processed, the btree which fs root owns might be changed, so we
    have to search it again for the highest objectid, otherwise creating
    new inode would end up with -EEXIST.
    
    cc: <[email protected]> v4.4-rc6+
    Fixes: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots")
    Signed-off-by: Liu Bo <[email protected]>
    Reviewed-by: Josef Bacik <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
---
 fs/btrfs/tree-log.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 79af4ae042ae..61f20c367aaf 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -28,6 +28,7 @@
 #include "hash.h"
 #include "compression.h"
 #include "qgroup.h"
+#include "inode-map.h"
 
 /* magic values for the inode_only field in btrfs_log_inode:
  *
@@ -5685,6 +5686,23 @@ again:
 						      path);
 		}
 
+		if (!ret && wc.stage == LOG_WALK_REPLAY_ALL) {
+			struct btrfs_root *root = wc.replay_dest;
+
+			btrfs_release_path(path);
+
+			/*
+			 * We have just replayed everything, and the highest
+			 * objectid of fs roots probably has changed in case
+			 * some inode_item's got replayed.
+			 *
+			 * root->objectid_mutex is not acquired as log replay
+			 * could only happen during mount.
+			 */
+			ret = btrfs_find_highest_objectid(root,
+						  &root->highest_objectid);
+		}
+
 		key.offset = found_key.offset - 1;
 		wc.replay_dest->log_root = NULL;
 		free_extent_buffer(log->node);
--
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html