From: Stephen Rothwell <sfr@canb•auug.org.au>
To: Christian Brauner <brauner@kernel•org>, David Sterba <dsterba@suse•cz>
Cc: David Sterba <dsterba@suse•com>,
Haisu Wang <haisuwang@tencent•com>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>,
"Matthew Wilcox (Oracle)" <willy@infradead•org>,
Qu Wenruo <wqu@suse•com>
Subject: linux-next: manual merge of the vfs-brauner tree with the btrfs tree
Date: Fri, 1 Nov 2024 09:22:12 +1100 [thread overview]
Message-ID: <20241101092212.1c112872@canb.auug.org.au> (raw)
[-- Attachment #1: Type: text/plain, Size: 6041 bytes --]
Hi all,
Today's linux-next merge of the vfs-brauner tree got a conflict in:
fs/btrfs/inode.c
between commits:
530eec3e0f6e ("btrfs: simplify range tracking in cow_file_range()")
25e40a35c927 ("btrfs: extract the inner loop of cow_file_range() to enhance the error handling")
from the btrfs tree and commit:
a6752a6e7fb0 ("btrfs: Switch from using the private_2 flag to owner_2")
from the vfs-brauner 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/inode.c
index 6ec223f9987f,c14e37438a0b..000000000000
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@@ -1293,147 -1320,6 +1293,147 @@@ u64 btrfs_get_extent_allocation_hint(st
return alloc_hint;
}
+/*
+ * Run one cow range, which includes:
+ *
+ * - Reserve the data extent
+ * - Create the io extent map
+ * - Create the ordered extent
+ *
+ * @ins will be updated if the range should be skipped for error handling, no
+ * matter the return value.
+ *
+ * Return 0 if everything is fine.
+ * Return -EAGAIN if btrfs_reserve_extent() failed for zoned fs, caller needs
+ * some extra handling.
+ * Return <0 for other errors.
+ */
+static int run_one_cow_range(struct btrfs_inode *inode,
+ struct folio *locked_folio,
+ struct btrfs_key *ins,
+ u64 start,
+ u64 end, u64 *alloc_hint, bool keep_locked)
+{
+ struct btrfs_root *root = inode->root;
+ struct btrfs_fs_info *fs_info = root->fs_info;
+ struct btrfs_ordered_extent *ordered;
+ struct btrfs_file_extent file_extent = { 0 };
+ struct extent_state *cached = NULL;
+ struct extent_map *em = NULL;
+ unsigned long page_ops;
+ const u64 len = end + 1 - start;
+ u32 min_alloc_size;
+ int ret;
+
+ ASSERT(IS_ALIGNED(start, fs_info->sectorsize));
+ ASSERT(IS_ALIGNED(end + 1, fs_info->sectorsize));
+
+ ins->offset = 0;
+ ins->objectid = 0;
+
+ /*
+ * Relocation relies on the relocated extents to have exactly the same
+ * size as the original extents. Normally writeback for relocation data
+ * extents follows a NOCOW path because relocation preallocates the
+ * extents. However, due to an operation such as scrub turning a block
+ * group to RO mode, it may fallback to COW mode, so we must make sure
+ * an extent allocated during COW has exactly the requested size and can
+ * not be split into smaller extents, otherwise relocation breaks and
+ * fails during the stage where it updates the bytenr of file extent
+ * items.
+ */
+ if (btrfs_is_data_reloc_root(root))
+ min_alloc_size = len;
+ else
+ min_alloc_size = fs_info->sectorsize;
+
+ ret = btrfs_reserve_extent(root, len, len, min_alloc_size, 0,
+ *alloc_hint, ins, 1, 1);
+ if (ret < 0)
+ return ret;
+
+ file_extent.disk_bytenr = ins->objectid;
+ file_extent.disk_num_bytes = ins->offset;
+ file_extent.num_bytes = ins->offset;
+ file_extent.ram_bytes = ins->offset;
+ file_extent.offset = 0;
+ file_extent.compression = BTRFS_COMPRESS_NONE;
+
+ lock_extent(&inode->io_tree, start, start + ins->offset - 1,
+ &cached);
+
+ em = btrfs_create_io_em(inode, start, &file_extent,
+ BTRFS_ORDERED_REGULAR);
+ if (IS_ERR(em)) {
+ unlock_extent(&inode->io_tree, start,
+ start + ins->offset - 1, &cached);
+ ret = PTR_ERR(em);
+ goto out_free_reserved;
+ }
+ free_extent_map(em);
+
+ ordered = btrfs_alloc_ordered_extent(inode, start, &file_extent,
+ 1 << BTRFS_ORDERED_REGULAR);
+ if (IS_ERR(ordered)) {
+ unlock_extent(&inode->io_tree, start,
+ start + ins->offset - 1, &cached);
+ ret = PTR_ERR(ordered);
+ goto out_drop_em;
+ }
+
+ if (btrfs_is_data_reloc_root(root)) {
+ ret = btrfs_reloc_clone_csums(ordered);
+
+ /*
+ * Only drop cache here, and process as normal.
+ *
+ * We must not allow extent_clear_unlock_delalloc()
+ * at error handling to free meta of this ordered
+ * extent, as its meta should be freed by
+ * btrfs_finish_ordered_io().
+ *
+ * So we must continue until @start is increased to
+ * skip current ordered extent.
+ */
+ if (ret < 0)
+ btrfs_drop_extent_map_range(inode, start,
+ start + ins->offset - 1,
+ false);
+ }
+ btrfs_put_ordered_extent(ordered);
+
+ btrfs_dec_block_group_reservations(fs_info, ins->objectid);
+
+ /*
+ * We're not doing compressed IO, don't unlock the first page
+ * (which the caller expects to stay locked), don't clear any
+ * dirty bits and don't set any writeback bits
+ *
- * Do set the Ordered (Private2) bit so we know this page was
++ * Do set the Ordered flag so we know this page was
+ * properly setup for writepage.
+ */
+ page_ops = (keep_locked ? 0 : PAGE_UNLOCK);
+ page_ops |= PAGE_SET_ORDERED;
+
+ extent_clear_unlock_delalloc(inode, start, start + ins->offset - 1,
+ locked_folio, &cached,
+ EXTENT_LOCKED | EXTENT_DELALLOC,
+ page_ops);
+ *alloc_hint = ins->objectid + ins->offset;
+ return ret;
+
+out_drop_em:
+ btrfs_drop_extent_map_range(inode, start, start + ins->offset - 1, false);
+out_free_reserved:
+ btrfs_dec_block_group_reservations(fs_info, ins->objectid);
+ btrfs_free_reserved_extent(fs_info, ins->objectid, ins->offset, 1);
+ /* This is reserved for btrfs_reserve_extent() error. */
+ ASSERT(ret != -EAGAIN);
+ ins->offset = 0;
+ ins->objectid = 0;
+ return ret;
+}
+
/*
* when extent_io.c finds a delayed allocation range in the file,
* the call backs end up in this code. The basic idea is to
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2024-10-31 22:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-31 22:22 Stephen Rothwell [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-11-02 21:58 linux-next: manual merge of the vfs-brauner tree with the btrfs tree Stephen Rothwell
2025-12-02 0:58 ` Stephen Rothwell
2024-10-15 21:51 Stephen Rothwell
2024-11-18 22:16 ` Stephen Rothwell
2024-06-18 11:41 Mark Brown
2024-07-16 0:58 ` Stephen Rothwell
2024-05-03 1:00 Stephen Rothwell
2024-05-14 1:38 ` Stephen Rothwell
2024-04-30 23:42 Stephen Rothwell
2023-12-06 23:32 Stephen Rothwell
2024-01-08 20:56 ` Stephen Rothwell
2023-11-26 22:20 Stephen Rothwell
2023-11-28 21:33 ` Nathan Chancellor
2023-11-29 11:09 ` Jan Kara
2023-11-29 20:50 ` Stephen Rothwell
2024-01-08 20:53 ` Stephen Rothwell
2023-11-26 22:14 Stephen Rothwell
2023-10-08 23:48 Stephen Rothwell
2023-10-09 16:15 ` Christian Brauner
2023-10-10 21:37 ` Stephen Rothwell
2023-10-11 0:24 ` Stephen Rothwell
2023-10-11 9:20 ` David Sterba
2023-10-12 15:42 ` David Sterba
2023-10-23 17:55 ` David Sterba
2023-10-23 21:25 ` Stephen Rothwell
2023-10-24 15:32 ` David Sterba
2023-10-25 0:09 ` Stephen Rothwell
2023-08-15 1:20 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=20241101092212.1c112872@canb.auug.org.au \
--to=sfr@canb$(echo .)auug.org.au \
--cc=brauner@kernel$(echo .)org \
--cc=dsterba@suse$(echo .)com \
--cc=dsterba@suse$(echo .)cz \
--cc=haisuwang@tencent$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=willy@infradead$(echo .)org \
--cc=wqu@suse$(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