On 2020/4/27 下午11:29, David Sterba wrote: > 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. > Checked the final code. Looks good, especially after that chunk allocation, we would have less chance to hit BUG_ON() due to ENOSPC in btrfs_record_root_in_trans(). Thanks for the merge, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
