This is a note to let you know that I've just added the patch titled
btrfs: fix iomap_begin length for nocow writes
to the 6.3-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
btrfs-fix-iomap_begin-length-for-nocow-writes.patch
and it can be found in the queue-6.3 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 7833b865953c8e62abc76a3261c04132b2fb69de Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@xxxxxx>
Date: Thu, 8 Jun 2023 11:10:25 +0200
Subject: btrfs: fix iomap_begin length for nocow writes
From: Christoph Hellwig <hch@xxxxxx>
commit 7833b865953c8e62abc76a3261c04132b2fb69de upstream.
can_nocow_extent can reduce the len passed in, which needs to be
propagated to btrfs_dio_iomap_begin so that iomap does not submit
more data then is mapped.
This problems exists since the btrfs_get_blocks_direct helper was added
in commit c5794e51784a ("btrfs: Factor out write portion of
btrfs_get_blocks_direct"), but the ordered_extent splitting added in
commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit")
added a WARN_ON that made a syzkaller test fail.
Reported-by: syzbot+ee90502d5c8fd1d0dd93@xxxxxxxxxxxxxxxxxxxxxxxxx
Fixes: c5794e51784a ("btrfs: Factor out write portion of btrfs_get_blocks_direct")
CC: stable@xxxxxxxxxxxxxxx # 6.1+
Tested-by: syzbot+ee90502d5c8fd1d0dd93@xxxxxxxxxxxxxxxxxxxxxxxxx
Reviewed-by: Filipe Manana <fdmanana@xxxxxxxx>
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: David Sterba <dsterba@xxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
fs/btrfs/inode.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -7324,7 +7324,7 @@ static struct extent_map *create_io_em(s
static int btrfs_get_blocks_direct_write(struct extent_map **map,
struct inode *inode,
struct btrfs_dio_data *dio_data,
- u64 start, u64 len,
+ u64 start, u64 *lenp,
unsigned int iomap_flags)
{
const bool nowait = (iomap_flags & IOMAP_NOWAIT);
@@ -7335,6 +7335,7 @@ static int btrfs_get_blocks_direct_write
struct btrfs_block_group *bg;
bool can_nocow = false;
bool space_reserved = false;
+ u64 len = *lenp;
u64 prev_len;
int ret = 0;
@@ -7405,15 +7406,19 @@ static int btrfs_get_blocks_direct_write
free_extent_map(em);
*map = NULL;
- if (nowait)
- return -EAGAIN;
+ if (nowait) {
+ ret = -EAGAIN;
+ goto out;
+ }
/*
* If we could not allocate data space before locking the file
* range and we can't do a NOCOW write, then we have to fail.
*/
- if (!dio_data->data_space_reserved)
- return -ENOSPC;
+ if (!dio_data->data_space_reserved) {
+ ret = -ENOSPC;
+ goto out;
+ }
/*
* We have to COW and we have already reserved data space before,
@@ -7454,6 +7459,7 @@ out:
btrfs_delalloc_release_extents(BTRFS_I(inode), len);
btrfs_delalloc_release_metadata(BTRFS_I(inode), len, true);
}
+ *lenp = len;
return ret;
}
@@ -7630,7 +7636,7 @@ static int btrfs_dio_iomap_begin(struct
if (write) {
ret = btrfs_get_blocks_direct_write(&em, inode, dio_data,
- start, len, flags);
+ start, &len, flags);
if (ret < 0)
goto unlock_err;
unlock_extents = true;
Patches currently in stable-queue which might be from hch@xxxxxx are
queue-6.3/btrfs-handle-memory-allocation-failure-in-btrfs_csum.patch
queue-6.3/btrfs-fix-iomap_begin-length-for-nocow-writes.patch
queue-6.3/btrfs-subpage-fix-a-crash-in-metadata-repair-path.patch
queue-6.3/nvme-add-maxio-1602-to-bogus-nid-list.patch
