On 2020/5/1 上午9:05, Stephen Rothwell wrote: > Hi all, > > On Fri, 1 May 2020 10:24:53 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: >> >> Today's linux-next merge of the btrfs tree got a conflict in: >> >> fs/btrfs/transaction.c >> >> between commit: >> >> fcc99734d1d4 ("btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info") >> >> from the btrfs-fixes tree and commit: >> >> f12ca53a6fd6 ("btrfs: force chunk allocation if our global rsv is larger than metadata") >> >> from the btrfs tree. >> >> I fixed it up (see below) and can carry the fix as necessary. This >> is now fixed as far as linux-next is concerned, but any non trivial >> conflicts should be mentioned to your upstream maintainer when your tree >> is submitted for merging. You may also want to consider cooperating >> with the maintainer of the conflicting tree to minimise any particularly >> complex conflicts. >> >> -- >> Cheers, >> Stephen Rothwell >> >> diff --cc fs/btrfs/transaction.c >> index 2d5498136e5e,e4dbd8e3c641..000000000000 >> --- a/fs/btrfs/transaction.c >> +++ b/fs/btrfs/transaction.c >> @@@ -666,15 -674,17 +672,26 @@@ got_it >> current->journal_info = h; >> >> /* >> + * btrfs_record_root_in_trans() needs 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); >> + >> + * If the space_info is marked ALLOC_FORCE then we'll get upgraded to >> + * ALLOC_FORCE the first run through, and then we won't allocate for >> + * anybody else who races in later. We don't care about the return >> + * value here. >> + */ >> + if (do_chunk_alloc && num_bytes) { >> + u64 flags = h->block_rsv->space_info->flags; >> + btrfs_chunk_alloc(h, btrfs_get_alloc_profile(fs_info, flags), >> + CHUNK_ALLOC_NO_FORCE); >> + } >> + >> return h; The proper fix has landed in David's misc-next branch, which puts btrfs_record_root_in_trans(); after the if () {} code block. By that, btrfs_record_root_in_trans() has lesser chance to hit ENOSPC. Thanks, Qu >> >> join_fail: > > > I fixed the missing comment start in my resolution ... >
Attachment:
signature.asc
Description: OpenPGP digital signature