[PATCH] Btrfs: fix unexpected -EEXIST when creating new inode

[PATCH] Btrfs: fix unexpected -EEXIST when creating new inode

[Liu Bo]

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: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots")
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
---
 fs/btrfs/tree-log.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index a7e6235..646cdbf 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:
  *
@@ -5715,6 +5716,24 @@ 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);
-- 
2.9.4

Re: [PATCH] Btrfs: fix unexpected -EEXIST when creating new inode

[Nikolay Borisov]

On 25.01.2018 20:02, Liu Bo wrote:
> 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: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots")
> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> ---
>  fs/btrfs/tree-log.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
> index a7e6235..646cdbf 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:
>   *
> @@ -5715,6 +5716,24 @@ 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.
> +			 */
> +			/*

nit: No need to start a new multiline comment

> +			 * 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);
> 

Re: [PATCH] Btrfs: fix unexpected -EEXIST when creating new inode

[Josef Bacik]

On Thu, Jan 25, 2018 at 11:02:56AM -0700, Liu Bo wrote:
> 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: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots")
> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> ---

Eesh that's bad.

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

Thanks,

Josef

Re: [PATCH] Btrfs: fix unexpected -EEXIST when creating new inode

[Filipe Manana]

On Thu, Jan 25, 2018 at 6:02 PM, Liu Bo <bo.li.liu@oracle.com> wrote:
> 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: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots")
> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>

Hi Bo,

Any reason to not have submitted a test case for fstests?
Unless I missed something this should be easy to reproduce, deterministic issue.

thanks

> ---
>  fs/btrfs/tree-log.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
> index a7e6235..646cdbf 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:
>   *
> @@ -5715,6 +5716,24 @@ 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);
> --
> 2.9.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

Re: [PATCH] Btrfs: fix unexpected -EEXIST when creating new inode

[Liu Bo]

On Wed, Feb 28, 2018 at 04:06:40PM +0000, Filipe Manana wrote:
> On Thu, Jan 25, 2018 at 6:02 PM, Liu Bo <bo.li.liu@oracle.com> wrote:
> > 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: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots")
> > Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> 
> Hi Bo,
> 
> Any reason to not have submitted a test case for fstests?
> Unless I missed something this should be easy to reproduce, deterministic issue.
>

It's on my todo list for a while until I forgot it...will do after I
fix the bugs I have now.

I found this originally from running generic/475.

Thanks,

-liubo
> thanks
> 
> > ---
> >  fs/btrfs/tree-log.c | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
> > index a7e6235..646cdbf 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:
> >   *
> > @@ -5715,6 +5716,24 @@ 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);
> > --
> > 2.9.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> -- 
> Filipe David Manana,
> 
> “Whether you think you can, or you think you can't — you're right.”