| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20240711-b4-rst-updates-v2-3-d7b8113d88b7@kernel.org> Date: Thu, 11 Jul 2024 08:21:32 +0200 From: Johannes Thumshirn <jth@...nel.org> To: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com> Cc: linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org, Qu Wenru <wqu@...e.com>, Filipe Manana <fdmanana@...e.com>, Johannes Thumshirn <johannes.thumshirn@....com> Subject: [PATCH v2 3/3] btrfs: update stripe_extent delete loop assumptions From: Johannes Thumshirn <johannes.thumshirn@....com> btrfs_delete_raid_extent() was written under the assumption, that it's call-chain always passes a start, length tuple that matches a single extent. But btrfs_delete_raid_extent() is called by do_free_extent_acounting() which in term is called by __btrfs_free_extent(). But this call-chain passes in a start address and a length that can possibly match multiple on-disk extents. To make this possible, we have to adjust the start and length of each btree node lookup, to not delete beyond the requested range. Signed-off-by: Johannes Thumshirn <johannes.thumshirn@....com> --- fs/btrfs/raid-stripe-tree.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/btrfs/raid-stripe-tree.c b/fs/btrfs/raid-stripe-tree.c index fd56535b2289..6f65be334637 100644 --- a/fs/btrfs/raid-stripe-tree.c +++ b/fs/btrfs/raid-stripe-tree.c @@ -66,6 +66,11 @@ int btrfs_delete_raid_extent(struct btrfs_trans_handle *trans, u64 start, u64 le if (ret) break; + start += key.offset; + length -= key.offset; + if (length == 0) + break; + btrfs_release_path(path); } -- 2.43.0
Powered by blists - more mailing lists