Re: [PATCH] btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 27, 2020 at 02:50:14PM +0800, Qu Wenruo wrote:
> index 8cede6eb9843..132bf2f1aa0d 100644
> --- a/fs/btrfs/transaction.c
> +++ b/fs/btrfs/transaction.c
> @@ -662,10 +662,19 @@ start_transaction(struct btrfs_root *root, unsigned int num_items,
>  	}
>  
>  got_it:
> -	btrfs_record_root_in_trans(h, root);
> -
>  	if (!current->journal_info)
>  		current->journal_info = h;
> +
> +	/*
> +	 * btrfs_record_root_in_trans() need to alloc new extents, and may
> +	 * call btrfs_join_transaction() while we're also starting a
> +	 * transaction.
> +	 *
> +	 * Thus it need to be called after current->journal_info initialized,
> +	 * or we can deadlock.
> +	 */
> +	btrfs_record_root_in_trans(h, root);

This applies cleanly on master, so that's fine as it'll go as a fix in
this dev cycle, but there's a conflict with misc-next patch "btrfs:
force chunk allocation if our global rsv is larger than metadata".

There's a chunk allocation added:

	btrfs_record_root_in_trans(...)
	if (!current->journal_info)
		...
	if (do_chunk_alloc ...)
		btrfs_chunk_alloc(...)

so the call btrfs_record_root_in_trans() should be moved after the chunk
allocation, to potentially use the newly added chunk. The merged order
is:

	if (!current->journal_info)
		...
	if (do_chunk_alloc ...)
		btrfs_chunk_alloc(...)
	btrfs_record_root_in_trans(...)

Please check if this is correct. Once this fix bubbles through master,
the conflicting patch in misc-next will have to be updated, but the end
result should remain. Thanks.



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux