Btrfs: fix unexpected -EEXIST when creating new inode (900c9981) · Commits · e / devices / android_kernel_fairphone_FP4

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: <stable@vger.kernel.org> v4.4-rc6+ Fixes: ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots") Signed-off-by:

Liu Bo <bo.li.liu@oracle.com> Reviewed-by:

Josef Bacik <jbacik@fb.com> Signed-off-by:

David Sterba <dsterba@suse.com>

fs/btrfs/tree-log.c

+18 −0

Original line number	Diff line number	Diff line
		@@ -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 @@ int btrfs_recover_log_trees(struct btrfs_root *log_root_tree)
		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);