From 0a9c35d3040d5aa6bb449b2f1e206cc0ac094343 Mon Sep 17 00:00:00 2001 From: Filipe Manana Date: Fri, 12 Jun 2026 15:54:31 +0100 Subject: [PATCH] btrfs: fix copy_remapped_data() to not allocate more memory than intended The loop intends to copy the data in chunks up to 1M but we allocate the pages array for the entire length and don't cap it to 1M. Fix this by computing 'nr_pages' using 'copy_len' instead of 'length'. While at it, also make 'nr_pages' and 'copy_len' const, as they never change, to make the code more clear. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Signed-off-by: David Sterba --- fs/btrfs/relocation.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 4f83415ee8f8..6a1817613036 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -4115,10 +4115,10 @@ static int copy_remapped_data(struct btrfs_fs_info *fs_info, u64 old_addr, u64 new_addr, u64 length) { int ret; - u64 copy_len = min_t(u64, length, SZ_1M); + const u64 copy_len = min_t(u64, length, SZ_1M); struct page **pages; struct reloc_io_private priv; - unsigned int nr_pages = DIV_ROUND_UP(length, PAGE_SIZE); + const unsigned int nr_pages = DIV_ROUND_UP(copy_len, PAGE_SIZE); pages = kzalloc_objs(struct page *, nr_pages, GFP_NOFS); if (!pages)