From: Mark Brown <broonie@kernel•org>
To: David Sterba <dsterba@suse•cz>
Cc: David Sterba <dsterba@suse•com>,
Filipe Manana <fdmanana@suse•com>,
KangNing Liao <lkangn.kernel@gmail•com>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>
Subject: linux-next: manual merge of the btrfs tree with the btrfs-fixes tree
Date: Tue, 2 Jun 2026 13:41:52 +0100 [thread overview]
Message-ID: <ah7PkPBnQ9jOkBQS@sirena.org.uk> (raw)
[-- Attachment #1: Type: text/plain, Size: 6479 bytes --]
Hi all,
Today's linux-next merge of the btrfs tree got a conflict in:
fs/btrfs/zoned.c
between commits:
c4dbdc9e2c61b ("btrfs: protect sb_write_pointer() with invalidate lock")
e67ae2bce5703 ("btrfs: use mapping shared locking for reading super block")
from the btrfs tree and commit:
6cfd0b77103ae ("btrfs: protect sb_write_pointer() with invalidate lock")
from the btrfs-fixes tree - there's a commit that's been duplicated in
the two trees there.
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 --combined fs/btrfs/zoned.c
index 5f75cf0e14b95,0f87701e38e34..0000000000000
--- a/fs/btrfs/zoned.c
+++ b/fs/btrfs/zoned.c
@@@ -131,10 -131,10 +131,10 @@@ static int sb_write_pointer(struct bloc
u64 bytenr = ALIGN_DOWN(zone_end, BTRFS_SUPER_INFO_SIZE) -
BTRFS_SUPER_INFO_SIZE;
- filemap_invalidate_lock(mapping);
+ filemap_invalidate_lock_shared(mapping);
page[i] = read_cache_page_gfp(mapping,
bytenr >> PAGE_SHIFT, GFP_NOFS);
- filemap_invalidate_unlock(mapping);
+ filemap_invalidate_unlock_shared(mapping);
if (IS_ERR(page[i])) {
if (i == 1)
btrfs_release_disk_super(super[0]);
@@@ -356,12 -356,33 +356,33 @@@ int btrfs_get_dev_zone_info_all_devices
return ret;
}
+ static int btrfs_get_max_active_zones(struct btrfs_device *device,
+ struct btrfs_zoned_device_info *zone_info)
+ {
+ struct block_device *bdev = device->bdev;
+ int max_active_zones;
+
+ if (unlikely(zone_info->nr_zones < BTRFS_MIN_ACTIVE_ZONES)) {
+ btrfs_err(device->fs_info, "zoned: not enough zones to mount filesystem: %u < %d",
+ zone_info->nr_zones, BTRFS_MIN_ACTIVE_ZONES);
+ return -EINVAL;
+ }
+
+ max_active_zones = min_not_zero(bdev_max_active_zones(bdev),
+ bdev_max_open_zones(bdev));
+ if (max_active_zones == 0)
+ max_active_zones = min(zone_info->nr_zones / 4,
+ BTRFS_DEFAULT_MAX_ACTIVE_ZONES);
+
+ zone_info->max_active_zones = max(max_active_zones, BTRFS_MIN_ACTIVE_ZONES);
+ return 0;
+ }
+
int btrfs_get_dev_zone_info(struct btrfs_device *device, bool populate_cache)
{
struct btrfs_fs_info *fs_info = device->fs_info;
struct btrfs_zoned_device_info *zone_info = NULL;
struct block_device *bdev = device->bdev;
- unsigned int max_active_zones;
unsigned int nactive;
sector_t nr_sectors;
sector_t sector = 0;
@@@ -426,19 -447,9 +447,9 @@@
if (!IS_ALIGNED(nr_sectors, zone_sectors))
zone_info->nr_zones++;
- max_active_zones = min_not_zero(bdev_max_active_zones(bdev),
- bdev_max_open_zones(bdev));
- if (!max_active_zones && zone_info->nr_zones > BTRFS_DEFAULT_MAX_ACTIVE_ZONES)
- max_active_zones = BTRFS_DEFAULT_MAX_ACTIVE_ZONES;
- if (max_active_zones && max_active_zones < BTRFS_MIN_ACTIVE_ZONES) {
- btrfs_err(fs_info,
- "zoned: %s: max active zones %u is too small, need at least %u active zones",
- rcu_dereference(device->name), max_active_zones,
- BTRFS_MIN_ACTIVE_ZONES);
- ret = -EINVAL;
+ ret = btrfs_get_max_active_zones(device, zone_info);
+ if (ret)
goto out;
- }
- zone_info->max_active_zones = max_active_zones;
zone_info->seq_zones = bitmap_zalloc(zone_info->nr_zones, GFP_KERNEL);
if (!zone_info->seq_zones) {
@@@ -519,26 -530,29 +530,29 @@@
goto out;
}
- if (max_active_zones) {
- if (unlikely(nactive > max_active_zones)) {
- if (bdev_max_active_zones(bdev) == 0) {
- max_active_zones = 0;
- zone_info->max_active_zones = 0;
- goto validate;
- }
+ if (unlikely(nactive > zone_info->max_active_zones)) {
+ if (bdev_max_active_zones(bdev) > 0) {
btrfs_err(device->fs_info,
- "zoned: %u active zones on %s exceeds max_active_zones %u",
- nactive, rcu_dereference(device->name),
- max_active_zones);
+ "zoned: %u active zones on %s exceeds max_active_zones %u",
+ nactive, rcu_dereference(device->name),
+ zone_info->max_active_zones);
ret = -EIO;
goto out;
}
+
+ /*
+ * This is for backward compatibility with old filesystems that
+ * have a lot of active zones because the device doesn't report
+ * a maximum number of zones and we previously didn't care for
+ * the limit.
+ */
+ zone_info->max_active_zones = 0;
+ } else {
atomic_set(&zone_info->active_zones_left,
- max_active_zones - nactive);
+ zone_info->max_active_zones - nactive);
set_bit(BTRFS_FS_ACTIVE_ZONE_TRACKING, &fs_info->flags);
}
- validate:
/* Validate superblock log */
nr_zones = BTRFS_NR_SB_LOG_ZONES;
for (i = 0; i < BTRFS_SUPER_MIRROR_MAX; i++) {
@@@ -1313,7 -1327,7 +1327,7 @@@ static int btrfs_load_zone_info(struct
{
struct btrfs_dev_replace *dev_replace = &fs_info->dev_replace;
struct btrfs_device *device;
- int dev_replace_is_ongoing = 0;
+ bool dev_replace_is_ongoing = false;
unsigned int nofs_flag;
struct blk_zone zone;
int ret;
@@@ -2765,7 -2779,6 +2779,6 @@@ void btrfs_zoned_reserve_data_reloc_bg(
struct btrfs_block_group *bg;
struct list_head *bg_list;
u64 alloc_flags;
- bool first = true;
bool did_chunk_alloc = false;
int index;
int ret;
@@@ -2782,18 -2795,13 +2795,13 @@@
alloc_flags = btrfs_get_alloc_profile(fs_info, space_info->flags);
index = btrfs_bg_flags_to_raid_index(alloc_flags);
- /* Scan the data space_info to find empty block groups. Take the second one. */
again:
bg_list = &space_info->block_groups[index];
list_for_each_entry(bg, bg_list, list) {
+
if (bg->alloc_offset != 0)
continue;
- if (first) {
- first = false;
- continue;
- }
-
if (space_info == data_sinfo) {
/* Migrate the block group to the data relocation space_info. */
struct btrfs_space_info *reloc_sinfo = data_sinfo->sub_group[0];
@@@ -2851,7 -2859,6 +2859,6 @@@
* We allocated a new block group in the data relocation space_info. We
* can take that one.
*/
- first = false;
did_chunk_alloc = true;
goto again;
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2026-06-02 12:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 12:41 Mark Brown [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-03-24 13:25 linux-next: manual merge of the btrfs tree with the btrfs-fixes tree Mark Brown
2026-03-24 13:25 Mark Brown
2026-03-17 13:48 Mark Brown
2026-03-17 13:48 Mark Brown
2026-03-17 13:48 Mark Brown
2025-09-18 11:26 Mark Brown
2024-06-06 22:55 Stephen Rothwell
2024-06-06 23:12 ` Qu Wenruo
2023-10-04 23:09 Stephen Rothwell
2022-10-31 23:28 Stephen Rothwell
2022-09-05 23:50 Stephen Rothwell
2022-09-06 0:15 ` Stephen Rothwell
2022-09-06 19:41 ` David Sterba
2022-03-24 23:48 Stephen Rothwell
2022-02-24 13:44 broonie
2022-02-25 11:59 ` David Sterba
2021-01-10 22:29 Stephen Rothwell
2020-05-01 0:28 Stephen Rothwell
2020-05-03 21:40 ` David Sterba
2020-05-01 0:24 Stephen Rothwell
2020-05-01 1:05 ` Stephen Rothwell
2020-05-01 2:06 ` Qu Wenruo
2020-01-08 22:14 Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ah7PkPBnQ9jOkBQS@sirena.org.uk \
--to=broonie@kernel$(echo .)org \
--cc=dsterba@suse$(echo .)com \
--cc=dsterba@suse$(echo .)cz \
--cc=fdmanana@suse$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=lkangn.kernel@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox