[PATCH] Btrfs: deal with unexpected return value in flush_space

[PATCH] Btrfs: deal with unexpected return value in flush_space

[Liu Bo]

Function start_transaction() can return ERR_PTR(1) when flush is
BTRFS_RESERVE_FLUSH_LIMIT, so the call graph is

start_transaction (return ERR_PTR(1))
  -> btrfs_block_rsv_add (return 1)
     -> reserve_metadata_bytes (return 1)
        -> flush_space (return 1)
           -> do_chunk_alloc  (return 1)

With BTRFS_RESERVE_FLUSH_LIMIT, if flush_space is already on the
flush_state of ALLOC_CHUNK and it successfully allocates a new
chunk, then instead of trying to reserve space again,
reserve_metadata_bytes returns 1 immediately.

Eventually the callers who call start_transaction() usually just
do the IS_ERR() check which ERR_PTR(1) can pass, then it'll get
a panic when dereferencing a pointer which is ERR_PTR(1).

This makes flush_space() translate 'ret = 1' to 'ret = 0'.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
---
We found this 'NULL pointer dereference' on an old 3.8 kernel but
it's not going to happen on the upstream since there is no caller
of btrfs_start_transaction_lflush().

 fs/btrfs/extent-tree.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 7a35c9d..a00fb67 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4457,6 +4457,15 @@ void check_system_chunk(struct btrfs_trans_handle *trans,
 	}
 }
 
+/*
+ * If force is CHUNK_ALLOC_FORCE:
+ *    - return 1 if it successfully allocates a chunk,
+ *    - return errors including -ENOSPC otherwise.
+ * If force is NOT CHUNK_ALLOC_FORCE:
+ *    - return 0 if it doesn't need to allocate a new chunk,
+ *    - return 1 if it successfully allocates a chunk,
+ *    - return errors including -ENOSPC otherwise.
+ */
 static int do_chunk_alloc(struct btrfs_trans_handle *trans,
 			  struct btrfs_root *extent_root, u64 flags, int force)
 {
@@ -4857,7 +4866,7 @@ static int flush_space(struct btrfs_root *root,
 				     btrfs_get_alloc_profile(root, 0),
 				     CHUNK_ALLOC_NO_FORCE);
 		btrfs_end_transaction(trans, root);
-		if (ret == -ENOSPC)
+		if (ret == -ENOSPC || ret == 1)
 			ret = 0;
 		break;
 	case COMMIT_TRANS:
-- 
2.5.5

Re: [PATCH] Btrfs: deal with unexpected return value in flush_space

[Holger Hoffstätte]

On Wed, 27 Jul 2016 18:42:03 -0700, Liu Bo wrote:

> Function start_transaction() can return ERR_PTR(1) when flush is
> BTRFS_RESERVE_FLUSH_LIMIT, so the call graph is
> 
> start_transaction (return ERR_PTR(1))
>   -> btrfs_block_rsv_add (return 1)
>      -> reserve_metadata_bytes (return 1)
>         -> flush_space (return 1)
>            -> do_chunk_alloc  (return 1)
> 
> With BTRFS_RESERVE_FLUSH_LIMIT, if flush_space is already on the
> flush_state of ALLOC_CHUNK and it successfully allocates a new
> chunk, then instead of trying to reserve space again,
> reserve_metadata_bytes returns 1 immediately.
> 
> Eventually the callers who call start_transaction() usually just
> do the IS_ERR() check which ERR_PTR(1) can pass, then it'll get
> a panic when dereferencing a pointer which is ERR_PTR(1).
> 
> This makes flush_space() translate 'ret = 1' to 'ret = 0'.
> 
> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> ---
> We found this 'NULL pointer dereference' on an old 3.8 kernel but
> it's not going to happen on the upstream since there is no caller
> of btrfs_start_transaction_lflush().
> 
>  fs/btrfs/extent-tree.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 7a35c9d..a00fb67 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -4457,6 +4457,15 @@ void check_system_chunk(struct btrfs_trans_handle *trans,
>  	}
>  }
>  
> +/*
> + * If force is CHUNK_ALLOC_FORCE:
> + *    - return 1 if it successfully allocates a chunk,
> + *    - return errors including -ENOSPC otherwise.
> + * If force is NOT CHUNK_ALLOC_FORCE:
> + *    - return 0 if it doesn't need to allocate a new chunk,
> + *    - return 1 if it successfully allocates a chunk,
> + *    - return errors including -ENOSPC otherwise.
> + */
>  static int do_chunk_alloc(struct btrfs_trans_handle *trans,
>  			  struct btrfs_root *extent_root, u64 flags, int force)
>  {
> @@ -4857,7 +4866,7 @@ static int flush_space(struct btrfs_root *root,
>  				     btrfs_get_alloc_profile(root, 0),
>  				     CHUNK_ALLOC_NO_FORCE);
>  		btrfs_end_transaction(trans, root);
> -		if (ret == -ENOSPC)
> +		if (ret == -ENOSPC || ret == 1)
>  			ret = 0;
>  		break;
>  	case COMMIT_TRANS:
> -- 
> 2.5.5

For reviewers - this came up before here:
https://patchwork.kernel.org/patch/7778651/

Same fix basically.

-h

Re: [PATCH] Btrfs: deal with unexpected return value in flush_space

[Liu Bo]

On Thu, Jul 28, 2016 at 03:36:53PM +0000, Holger Hoffstätte wrote:
> On Wed, 27 Jul 2016 18:42:03 -0700, Liu Bo wrote:
> 
> > Function start_transaction() can return ERR_PTR(1) when flush is
> > BTRFS_RESERVE_FLUSH_LIMIT, so the call graph is
> > 
> > start_transaction (return ERR_PTR(1))
> >   -> btrfs_block_rsv_add (return 1)
> >      -> reserve_metadata_bytes (return 1)
> >         -> flush_space (return 1)
> >            -> do_chunk_alloc  (return 1)
> > 
> > With BTRFS_RESERVE_FLUSH_LIMIT, if flush_space is already on the
> > flush_state of ALLOC_CHUNK and it successfully allocates a new
> > chunk, then instead of trying to reserve space again,
> > reserve_metadata_bytes returns 1 immediately.
> > 
> > Eventually the callers who call start_transaction() usually just
> > do the IS_ERR() check which ERR_PTR(1) can pass, then it'll get
> > a panic when dereferencing a pointer which is ERR_PTR(1).
> > 
> > This makes flush_space() translate 'ret = 1' to 'ret = 0'.
> > 
> > Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> > ---
> > We found this 'NULL pointer dereference' on an old 3.8 kernel but
> > it's not going to happen on the upstream since there is no caller
> > of btrfs_start_transaction_lflush().
> > 
> >  fs/btrfs/extent-tree.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> > index 7a35c9d..a00fb67 100644
> > --- a/fs/btrfs/extent-tree.c
> > +++ b/fs/btrfs/extent-tree.c
> > @@ -4457,6 +4457,15 @@ void check_system_chunk(struct btrfs_trans_handle *trans,
> >  	}
> >  }
> >  
> > +/*
> > + * If force is CHUNK_ALLOC_FORCE:
> > + *    - return 1 if it successfully allocates a chunk,
> > + *    - return errors including -ENOSPC otherwise.
> > + * If force is NOT CHUNK_ALLOC_FORCE:
> > + *    - return 0 if it doesn't need to allocate a new chunk,
> > + *    - return 1 if it successfully allocates a chunk,
> > + *    - return errors including -ENOSPC otherwise.
> > + */
> >  static int do_chunk_alloc(struct btrfs_trans_handle *trans,
> >  			  struct btrfs_root *extent_root, u64 flags, int force)
> >  {
> > @@ -4857,7 +4866,7 @@ static int flush_space(struct btrfs_root *root,
> >  				     btrfs_get_alloc_profile(root, 0),
> >  				     CHUNK_ALLOC_NO_FORCE);
> >  		btrfs_end_transaction(trans, root);
> > -		if (ret == -ENOSPC)
> > +		if (ret == -ENOSPC || ret == 1)
> >  			ret = 0;
> >  		break;
> >  	case COMMIT_TRANS:
> > -- 
> > 2.5.5
> 
> For reviewers - this came up before here:
> https://patchwork.kernel.org/patch/7778651/
> 
> Same fix basically.

Aha, I've given it my Reviewed-by.

Taking either one works for me, I can make the clarifying comment into a
seperate patch if we need to.

Thanks,

-liubo

Re: [PATCH] Btrfs: deal with unexpected return value in flush_space

[David Sterba]

On Thu, Jul 28, 2016 at 11:49:14AM -0700, Liu Bo wrote:
> > For reviewers - this came up before here:
> > https://patchwork.kernel.org/patch/7778651/
> > 
> > Same fix basically.
> 
> Aha, I've given it my Reviewed-by.
> 
> Taking either one works for me, I can make the clarifying comment into a
> seperate patch if we need to.

I'll pick the first patch and please send the separate comment update.
Thanks.

Re: [PATCH] Btrfs: deal with unexpected return value in flush_space

[Liu Bo]

On Fri, Jul 29, 2016 at 07:01:50PM +0200, David Sterba wrote:
> On Thu, Jul 28, 2016 at 11:49:14AM -0700, Liu Bo wrote:
> > > For reviewers - this came up before here:
> > > https://patchwork.kernel.org/patch/7778651/

David, this patch made a mistake in commit log.

> > > 
> > > Same fix basically.
> > 
> > Aha, I've given it my Reviewed-by.
> > 
> > Taking either one works for me, I can make the clarifying comment into a
> > seperate patch if we need to.
> 
> I'll pick the first patch and please send the separate comment update.
> Thanks.

Sure.

Thanks,

-liubo

[PATCH v2] Btrfs: clarify do_chunk_alloc()'s return value

[Liu Bo]

Function start_transaction() can return ERR_PTR(1) when flush is
BTRFS_RESERVE_FLUSH_LIMIT, so the call graph is

start_transaction (return ERR_PTR(1))
  -> btrfs_block_rsv_add (return 1)
     -> reserve_metadata_bytes (return 1)
        -> flush_space (return 1)
           -> do_chunk_alloc  (return 1)

With BTRFS_RESERVE_FLUSH_LIMIT, if flush_space is already on the
flush_state of ALLOC_CHUNK and it successfully allocates a new
chunk, then instead of trying to reserve space again,
reserve_metadata_bytes returns 1 immediately.

Eventually the callers who call start_transaction() usually just
do the IS_ERR() check which ERR_PTR(1) can pass, then it'll get
a panic when dereferencing a pointer which is ERR_PTR(1).

The following patch fixes the above problem.
"btrfs: flush_space: treat return value of do_chunk_alloc properly"
https://patchwork.kernel.org/patch/7778651/

This add comments to clarify do_chunk_alloc()'s return value.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
---
v2: Since there is already a patch fixing the problem, lets do the 
    comment part separately.

 fs/btrfs/extent-tree.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 7a35c9d..921cde6 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4457,6 +4457,15 @@ void check_system_chunk(struct btrfs_trans_handle *trans,
 	}
 }
 
+/*
+ * If force is CHUNK_ALLOC_FORCE:
+ *    - return 1 if it successfully allocates a chunk,
+ *    - return errors including -ENOSPC otherwise.
+ * If force is NOT CHUNK_ALLOC_FORCE:
+ *    - return 0 if it doesn't need to allocate a new chunk,
+ *    - return 1 if it successfully allocates a chunk,
+ *    - return errors including -ENOSPC otherwise.
+ */
 static int do_chunk_alloc(struct btrfs_trans_handle *trans,
 			  struct btrfs_root *extent_root, u64 flags, int force)
 {
-- 
2.5.5

Re: [PATCH v2] Btrfs: clarify do_chunk_alloc()'s return value

[David Sterba]

On Fri, Jul 29, 2016 at 11:09:50AM -0700, Liu Bo wrote:
> Function start_transaction() can return ERR_PTR(1) when flush is
> BTRFS_RESERVE_FLUSH_LIMIT, so the call graph is
> 
> start_transaction (return ERR_PTR(1))
>   -> btrfs_block_rsv_add (return 1)
>      -> reserve_metadata_bytes (return 1)
>         -> flush_space (return 1)
>            -> do_chunk_alloc  (return 1)
> 
> With BTRFS_RESERVE_FLUSH_LIMIT, if flush_space is already on the
> flush_state of ALLOC_CHUNK and it successfully allocates a new
> chunk, then instead of trying to reserve space again,
> reserve_metadata_bytes returns 1 immediately.
> 
> Eventually the callers who call start_transaction() usually just
> do the IS_ERR() check which ERR_PTR(1) can pass, then it'll get
> a panic when dereferencing a pointer which is ERR_PTR(1).
> 
> The following patch fixes the above problem.
> "btrfs: flush_space: treat return value of do_chunk_alloc properly"
> https://patchwork.kernel.org/patch/7778651/
> 
> This add comments to clarify do_chunk_alloc()'s return value.
> 
> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>

Patch queued, thanks.

Re: [PATCH] Btrfs: deal with unexpected return value in flush_space

[Alex Lyakas]

David, Holger,

Thank you for picking up that old patch of mine.

Alex.


On Fri, Jul 29, 2016 at 8:53 PM, Liu Bo <bo.li.liu@oracle.com> wrote:
> On Fri, Jul 29, 2016 at 07:01:50PM +0200, David Sterba wrote:
>> On Thu, Jul 28, 2016 at 11:49:14AM -0700, Liu Bo wrote:
>> > > For reviewers - this came up before here:
>> > > https://patchwork.kernel.org/patch/7778651/
>
> David, this patch made a mistake in commit log.
>
>> > >
>> > > Same fix basically.
>> >
>> > Aha, I've given it my Reviewed-by.
>> >
>> > Taking either one works for me, I can make the clarifying comment into a
>> > seperate patch if we need to.
>>
>> I'll pick the first patch and please send the separate comment update.
>> Thanks.
>
> Sure.
>
> Thanks,
>
> -liubo
> --
> 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