On 15.11.2017 23:20, Josef Bacik wrote:
> From: Josef Bacik <jba...@fb.com>
>
> If we fail to prepare our pages for whatever reason (out of memory in
> our case) we need to make sure to drop the block_group->data_rwsem,
> otherwise hilarity ensues.
>
> Signed-off-by: Josef Bacik <jba...@fb.com>
> ---
> fs/btrfs/free-space-cache.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
> index cdc9f4015ec3..a6c643275210 100644
> --- a/fs/btrfs/free-space-cache.c
> +++ b/fs/btrfs/free-space-cache.c
> @@ -1263,8 +1263,12 @@ static int __btrfs_write_out_cache(struct btrfs_root
> *root, struct inode *inode,
>
> /* Lock all pages first so we can lock the extent safely. */
> ret = io_ctl_prepare_pages(io_ctl, inode, 0);
> - if (ret)
> + if (ret) {
> + if (block_group &&
> + (block_group->flags & BTRFS_BLOCK_GROUP_DATA))
> + up_write(&block_group->data_rwsem);
> goto out;
> + }
Which function after out: label causes a deadlock - btrfs_update_inode
(unlikely) or invalidate_inode_pages2?
>
> lock_extent_bits(&BTRFS_I(inode)->io_tree, 0, i_size_read(inode) - 1,
> &cached_state);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
