Re: [PATCH 2/5] Btrfs: fix trans block rsv regression

[Josef Bacik <jbacik@fusionio.com>]

On Fri, Sep 14, 2012 at 02:58:04AM -0600, Liu Bo wrote:
> In some workloads we have nested joining transaction operations,
> eg.
>   run_delalloc_nocow
>       btrfs_join_transaction
>       cow_file_range
>          btrfs_join_transaction
> 
> it can be a serious bug since each trans handler has only two
> block_rsv, orig_rsv and block_rsv, which means we may lose our
> first block_rsv after two joining transaction operations:
> 
> 1) btrfs_start_transaction
>       trans->block_rsv = A
> 
> 2) btrfs_join_transaction
>       trans->orig_rsv = trans->block_rsv; ---> orig_rsv is now A
>       trans->block_rsv = B
> 
> 3) btrfs_join_transaction
>       trans->orig_rsv = trans->block_rsv; ---> orig_rsv is now B
>       trans->block_rsv = C
>    ...
> 

I'd like to see the actual stack trace where this happens, because I don't think
it can happen.  And if it is we need to look at that specific case and adjust it
as necessary and not add a bunch of kmallocs just to track the block_rsv,
because frankly it's not that big of a deal, it was just put into place in case
somebody wasn't expecting a call they made to start another transaction and
reset the block_rsv, which I don't actually think happens anywhere.  So NAK on
this patch, give me more information so I can figure out the right way to deal
with this.  Thanks,

Josef