linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

Hi all,

Today's linux-next merge of the btrfs tree got a conflict in:

  fs/btrfs/inode.c

between commit:

  045d3967b692 ("btrfs: rework arguments of btrfs_unlink_subvol")

from the btrfs-fixes tree and commit:

  f8b3030e0807 ("btrfs: rework arguments of btrfs_unlink_subvol")

from the btrfs tree.

I fixed it up (just different version of the same patch - I used the
former) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

Hi all,

Today's linux-next merge of the btrfs tree got a conflict in:

  fs/btrfs/transaction.h

between commit:

  f8d1b011ca8c ("btrfs: always print transaction aborted messages with an error level")

from the btrfs-fixes tree and commit:

  5483af73c851 ("btrfs: rename errno identifiers to error")

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.h
index 93869cda6af9,de58776de307..000000000000
--- a/fs/btrfs/transaction.h
+++ b/fs/btrfs/transaction.h
@@@ -213,15 -216,15 +216,15 @@@ do {								
  	if (!test_and_set_bit(BTRFS_FS_STATE_TRANS_ABORTED,	\
  			&((trans)->fs_info->fs_state))) {	\
  		first = true;					\
- 		if (WARN(abort_should_print_stack(errno),	\
+ 		if (WARN(abort_should_print_stack(error),	\
  			KERN_ERR				\
  			"BTRFS: Transaction aborted (error %d)\n",	\
- 			(errno))) {					\
+ 			(error))) {					\
  			/* Stack trace printed. */			\
  		} else {						\
 -			btrfs_debug((trans)->fs_info,			\
 -				    "Transaction aborted (error %d)", \
 +			btrfs_err((trans)->fs_info,			\
 +				  "Transaction aborted (error %d)",	\
- 				  (errno));			\
+ 				  (error));			\
  		}						\
  	}							\
  	__btrfs_abort_transaction((trans), __func__,		\

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

Hi all,

Today's linux-next merge of the btrfs tree got a conflict in:

  fs/btrfs/ctree.h

between commit:

  8184620ae212 ("btrfs: fix lost file sync on direct IO write with nowait and dsync iocb")

from the btrfs-fixes tree and commit:

  d98f802c975e ("btrfs: move inode prototypes to btrfs_inode.h")

from the btrfs tree.

I fixed it up (I used the latter version of this file and applied the
following merge fix patch) 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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 1 Nov 2022 10:24:24 +1100
Subject: [PATCH] fix up for "btrfs: fix lost file sync on direct IO write with nowait and dsync iocb"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/btrfs/btrfs_inode.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 79a9f06c2434..d21c30bf7053 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -526,7 +526,10 @@ ssize_t btrfs_encoded_read(struct kiocb *iocb, struct iov_iter *iter,
 ssize_t btrfs_do_encoded_write(struct kiocb *iocb, struct iov_iter *from,
 			       const struct btrfs_ioctl_encoded_io_args *encoded);
 
-ssize_t btrfs_dio_rw(struct kiocb *iocb, struct iov_iter *iter, size_t done_before);
+ssize_t btrfs_dio_read(struct kiocb *iocb, struct iov_iter *iter,
+		       size_t done_before);
+struct iomap_dio *btrfs_dio_write(struct kiocb *iocb, struct iov_iter *iter,
+				  size_t done_before);
 
 extern const struct dentry_operations btrfs_dentry_operations;
 
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[David Sterba]

On Tue, Sep 06, 2022 at 10:15:49AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 6 Sep 2022 09:50:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the btrfs tree got a conflict in:
> > 
> >   fs/btrfs/zoned.c
> > 
> > between commit:
> > 
> >   6ca64ac27631 ("btrfs: zoned: fix mounting with conventional zones")
> > 
> > from the btrfs-fixes tree and commit:
> > 
> >   e5182af66852 ("btrfs: convert block group bit field to use bit helpers")
> > 
> > from the btrfs tree.
> > 
> > I fixed it up (the former removed some of the code modified by the latter)
> > 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.
> 
> Actually the fix up is below ...

Thanks, looks correct to me. I've pushed a new for-next snapshot that
has the conflict resolved too.

Re: linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3056 bytes --]

Hi all,

On Tue, 6 Sep 2022 09:50:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the btrfs tree got a conflict in:
> 
>   fs/btrfs/zoned.c
> 
> between commit:
> 
>   6ca64ac27631 ("btrfs: zoned: fix mounting with conventional zones")
> 
> from the btrfs-fixes tree and commit:
> 
>   e5182af66852 ("btrfs: convert block group bit field to use bit helpers")
> 
> from the btrfs tree.
> 
> I fixed it up (the former removed some of the code modified by the latter)
> 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.

Actually the fix up is below ...

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/zoned.c
index 62e7007a7e46,dc96b3331bfb..000000000000
--- a/fs/btrfs/zoned.c
+++ b/fs/btrfs/zoned.c
@@@ -1426,17 -1402,32 +1426,16 @@@ int btrfs_load_block_group_zone_info(st
  		cache->seq_zone = true;
  
  	if (num_conventional > 0) {
 -		/*
 -		 * Avoid calling calculate_alloc_pointer() for new BG. It
 -		 * is no use for new BG. It must be always 0.
 -		 *
 -		 * Also, we have a lock chain of extent buffer lock ->
 -		 * chunk mutex.  For new BG, this function is called from
 -		 * btrfs_make_block_group() which is already taking the
 -		 * chunk mutex. Thus, we cannot call
 -		 * calculate_alloc_pointer() which takes extent buffer
 -		 * locks to avoid deadlock.
 -		 */
 -
  		/* Zone capacity is always zone size in emulation */
  		cache->zone_capacity = cache->length;
 -		if (new) {
 -			cache->alloc_offset = 0;
 -			goto out;
 -		}
 -		ret = calculate_alloc_pointer(cache, &last_alloc);
 -		if (ret || map->num_stripes == num_conventional) {
 -			if (!ret)
 -				cache->alloc_offset = last_alloc;
 -			else
 -				btrfs_err(fs_info,
 +		ret = calculate_alloc_pointer(cache, &last_alloc, new);
 +		if (ret) {
 +			btrfs_err(fs_info,
  			"zoned: failed to determine allocation offset of bg %llu",
 -					  cache->start);
 +				  cache->start);
 +			goto out;
 +		} else if (map->num_stripes == num_conventional) {
 +			cache->alloc_offset = last_alloc;
- 			cache->zone_is_active = 1;
  			goto out;
  		}
  	}
@@@ -1528,16 -1529,10 +1530,16 @@@ out
  		ret = -EIO;
  	}
  
 -	if (!ret)
 +	if (!ret) {
  		cache->meta_write_pointer = cache->alloc_offset + cache->start;
- 		if (cache->zone_is_active) {
 -
 -	if (ret) {
++		if (test_bit(BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE, &cache->runtime_flags)) {
 +			btrfs_get_block_group(cache);
 +			spin_lock(&fs_info->zone_active_bgs_lock);
 +			list_add_tail(&cache->active_bg_list,
 +				      &fs_info->zone_active_bgs);
 +			spin_unlock(&fs_info->zone_active_bgs_lock);
 +		}
 +	} else {
  		kfree(cache->physical_map);
  		cache->physical_map = NULL;
  	}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

Hi all,

Today's linux-next merge of the btrfs tree got a conflict in:

  fs/btrfs/zoned.c

between commit:

  6ca64ac27631 ("btrfs: zoned: fix mounting with conventional zones")

from the btrfs-fixes tree and commit:

  e5182af66852 ("btrfs: convert block group bit field to use bit helpers")

from the btrfs tree.

I fixed it up (the former removed some of the code modified by the latter)
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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Hi all,

Today's linux-next merge of the btrfs tree got a conflict in:

  fs/btrfs/zoned.c

between commits:

  0b9e66762aa0 ("btrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone")
  62ed0bf7315b ("btrfs: zoned: remove left over ASSERT checking for single profile")

from the btrfs-fixes tree and commits:

  71f3883a5968 ("btrfs: zoned: use RCU list in btrfs_can_activate_zone")
  7d5e73a6ef6c ("btrfs: zoned: remove left over ASSERT checking for single profile")

from the btrfs tree.

I fixed it up (I just (arbitrarily) chose the former version) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[David Sterba]

On Thu, Feb 24, 2022 at 01:44:27PM +0000, broonie@kernel.org wrote:
> Hi all,
> 
> Today's linux-next merge of the btrfs tree got conflicts in:
> 
>   fs/btrfs/ctree.h
>   fs/btrfs/file.c
>   fs/btrfs/inode.c
>   fs/btrfs/ioctl.c
>   fs/btrfs/lzo.c
> 
> between commit:
> 
>   2ac3e062af024 ("btrfs: reduce extent threshold for autodefrag")
>   741b23a970a79 ("btrfs: prevent copying too big compressed lzo segment")
>   26fbac2517fca ("btrfs: autodefrag: only scan one inode once")
>   966d879bafaaf ("btrfs: defrag: allow defrag_one_cluster() to skip large extent which is not a target")
>   d5633b0dee02d ("btrfs: defrag: bring back the old file extent search behavior")
> 
> from the btrfs-fixes tree and commit:
> 
>   13b2f7ab699a5 ("btrfs: close the gap between inode_should_defrag() and autodefrag extent size threshold")
>   48b433a2ef82a ("btrfs: add lzo workspace buffer length constants")
>   db360c49d476f ("btrfs: autodefrag: only scan one inode once")
>   e6c69fcbee7ef ("btrfs: defrag: use control structure in btrfs_defrag_file()")
>   6b17743d934ec ("btrfs: defrag: bring back the old file extent search behavior")
> 
> from the btrfs tree.

The fixes and for-next snapshot branches got out of sync a bit, I've
checked that they merge without conflicts as of yesterday.

linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[broonie]

Hi all,

Today's linux-next merge of the btrfs tree got conflicts in:

  fs/btrfs/ctree.h
  fs/btrfs/file.c
  fs/btrfs/inode.c
  fs/btrfs/ioctl.c
  fs/btrfs/lzo.c

between commit:

  2ac3e062af024 ("btrfs: reduce extent threshold for autodefrag")
  741b23a970a79 ("btrfs: prevent copying too big compressed lzo segment")
  26fbac2517fca ("btrfs: autodefrag: only scan one inode once")
  966d879bafaaf ("btrfs: defrag: allow defrag_one_cluster() to skip large extent which is not a target")
  d5633b0dee02d ("btrfs: defrag: bring back the old file extent search behavior")

from the btrfs-fixes tree and commit:

  13b2f7ab699a5 ("btrfs: close the gap between inode_should_defrag() and autodefrag extent size threshold")
  48b433a2ef82a ("btrfs: add lzo workspace buffer length constants")
  db360c49d476f ("btrfs: autodefrag: only scan one inode once")
  e6c69fcbee7ef ("btrfs: defrag: use control structure in btrfs_defrag_file()")
  6b17743d934ec ("btrfs: defrag: bring back the old file extent search behavior")

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.

diff --cc fs/btrfs/ctree.h
index 947f04789389e,5a569bc756c3c..0000000000000
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
diff --cc fs/btrfs/file.c
index 01111ee06e1ef,8815981447034..0000000000000
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
diff --cc fs/btrfs/inode.c
index 76e530f76e3cf,44e8d28182b7f..0000000000000
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
diff --cc fs/btrfs/ioctl.c
index 8d47ec5fc4f44,998bf48e5ce29..0000000000000
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@@ -1435,16 -1460,16 +1461,23 @@@ static int defrag_collect_targets(struc
  			goto add;
  
  		/* Skip too large extent */
- 		if (range_len >= extent_thresh)
+ 		if (range_len >= ctrl->extent_thresh)
+ 			goto next;
+ 
+ 		/*
+ 		 * Skip extents already at its max capacity, this is mostly for
+ 		 * compressed extents, which max cap is only 128K.
+ 		 */
+ 		if (em->len >= get_extent_max_capacity(em))
  			goto next;
  
 +		/*
 +		 * Skip extents already at its max capacity, this is mostly for
 +		 * compressed extents, which max cap is only 128K.
 +		 */
 +		if (em->len >= get_extent_max_capacity(em))
 +			goto next;
 +
  		next_mergeable = defrag_check_next_extent(&inode->vfs_inode, em,
  							  locked);
  		if (!next_mergeable) {
@@@ -1683,19 -1715,11 +1723,20 @@@ static int defrag_one_cluster(struct bt
  			break;
  		}
  
- 		if (max_sectors)
+ 		if (ctrl->max_sectors_to_defrag)
  			range_len = min_t(u32, range_len,
- 				(max_sectors - *sectors_defragged) * sectorsize);
+ 					  (ctrl->max_sectors_to_defrag -
+ 					   ctrl->sectors_defragged) * sectorsize);
  
 +		/*
 +		 * If defrag_one_range() has updated last_scanned_ret,
 +		 * our range may already be invalid (e.g. hole punched).
 +		 * Skip if our range is before last_scanned_ret, as there is
 +		 * no need to defrag the range anymore.
 +		 */
 +		if (entry->start + range_len <= *last_scanned_ret)
 +			continue;
 +
  		if (ra)
  			page_cache_sync_readahead(inode->vfs_inode.i_mapping,
  				ra, NULL, entry->start >> PAGE_SHIFT,
@@@ -1834,13 -1879,11 +1898,10 @@@ int btrfs_defrag_file(struct inode *ino
  			break;
  		}
  		if (do_compress)
- 			BTRFS_I(inode)->defrag_compress = compress_type;
- 		ret = defrag_one_cluster(BTRFS_I(inode), ra, cur,
- 				cluster_end + 1 - cur, extent_thresh,
- 				newer_than, do_compress, &sectors_defragged,
- 				max_to_defrag, &last_scanned);
 -			BTRFS_I(inode)->defrag_compress = ctrl->compress;
+ 		ret = defrag_one_cluster(BTRFS_I(inode), ra, ctrl, cur,
+ 					 cluster_end + 1 - cur);
  
- 		if (sectors_defragged > prev_sectors_defragged)
+ 		if (ctrl->sectors_defragged > prev_sectors_defragged)
  			balance_dirty_pages_ratelimited(inode->i_mapping);
  
  		btrfs_inode_unlock(inode, 0);
diff --cc fs/btrfs/lzo.c
index e6e28a9c79877,430ad36b8b080..0000000000000
--- a/fs/btrfs/lzo.c
+++ b/fs/btrfs/lzo.c


diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 7d3542893a165..5ef7c08b24b89 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1734,7 +1734,7 @@ static int defrag_one_cluster(struct btrfs_inode *inode,
 		 * Skip if our range is before last_scanned_ret, as there is
 		 * no need to defrag the range anymore.
 		 */
-		if (entry->start + range_len <= *last_scanned_ret)
+		if (entry->start + range_len <= ctrl->last_scanned)
 			continue;
 
 		if (ra)
@@ -1760,7 +1760,7 @@ static int defrag_one_cluster(struct btrfs_inode *inode,
 		kfree(entry);
 	}
 	if (ret >= 0)
-		*last_scanned_ret = max(*last_scanned_ret, start + len);
+		ctrl->last_scanned = max(ctrl->last_scanned, start + len);
 	return ret;
 }
 

linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

Hi all,

Today's linux-next merge of the btrfs tree got conflicts in:

  fs/btrfs/inode.c
  fs/btrfs/space-info.c

between commits:

  3d45f221ce62 ("btrfs: fix deadlock when cloning inline extent and low on free metadata space")
  e076ab2a2ca7 ("btrfs: shrink delalloc pages instead of full inodes")

from the btrfs-fixes tree and commits:

  50f2ad0e64bd ("btrfs: fix deadlock when cloning inline extent and low on free metadata space")
  123b5509410e ("btrfs: track ordered bytes instead of just dio ordered bytes")

from the btrfs tree.

I fixed it up (I used the former version of the conflicts in inode.c
and 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/inode.c
index a8e0a6b038d3,070716650df8..000000000000
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
diff --cc fs/btrfs/space-info.c
index e8347461c8dd,80f3edd6a391..000000000000
--- a/fs/btrfs/space-info.c
+++ b/fs/btrfs/space-info.c
@@@ -531,10 -527,8 +527,10 @@@ static void shrink_delalloc(struct btrf
  		wait_ordered = true;
  
  	loops = 0;
- 	while ((delalloc_bytes || dio_bytes) && loops < 3) {
+ 	while ((delalloc_bytes || ordered_bytes) && loops < 3) {
 -		btrfs_start_delalloc_roots(fs_info, items, true);
 +		u64 nr_pages = min(delalloc_bytes, to_reclaim) >> PAGE_SHIFT;
 +
 +		btrfs_start_delalloc_roots(fs_info, nr_pages, true);
  
  		loops++;
  		if (wait_ordered && !trans) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[David Sterba]

On Fri, May 01, 2020 at 10:28:25AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the btrfs tree got a conflict in:
> 
>   fs/btrfs/tree-log.c
> 
> between commit:
> 
>   f135cea30de5 ("btrfs: fix partial loss of prealloc extent past i_size after fsync")
> 
> from the btrfs-fixes tree and commit:
> 
>   e94d318f12cd ("btrfs: fix partial loss of prealloc extent past i_size after fsync")

Conflicts in the above commit and "btrfs: force chunk allocation if our
global rsv is larger than metadata" should be gone now. Both patches
have been merged to master and fresh for-next branch pushed to k.org.

Re: linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 2424 bytes --]



On 2020/5/1 上午9:05, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 1 May 2020 10:24:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]

Hi all,

On Fri, 1 May 2020 10:24:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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;
>   
>   join_fail:


I fixed the missing comment start in my resolution ...
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

Hi all,

Today's linux-next merge of the btrfs tree got a conflict in:

  fs/btrfs/tree-log.c

between commit:

  f135cea30de5 ("btrfs: fix partial loss of prealloc extent past i_size after fsync")

from the btrfs-fixes tree and commit:

  e94d318f12cd ("btrfs: fix partial loss of prealloc extent past i_size after fsync")

from the btrfs tree.

I fixed it up (I just used the latter) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the btrfs tree with the btrfs-fixes tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

Hi all,

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;
  
  join_fail:

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]