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
Hi all,
On Tue, 6 Sep 2022 09:50:55 +1000 Stephen Rothwell <[email protected]> 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;
}
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 <[email protected]> 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.