]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
btrfs: use btrfs_record_snapshot_destroy() during rmdir
authorFilipe Manana <fdmanana@suse.com>
Fri, 20 Jun 2025 15:37:01 +0000 (16:37 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 17 Jul 2025 16:24:59 +0000 (18:24 +0200)
commite2dec6cdb67802fa43c9b72a8770f6065efe617b
tree01f79229b5597efb024f891772ac2480877066b9
parentef761ccefc6b5c832c54037c176e36af3f0e0194
btrfs: use btrfs_record_snapshot_destroy() during rmdir

[ Upstream commit 157501b0469969fc1ba53add5049575aadd79d80 ]

We are setting the parent directory's last_unlink_trans directly which
may result in a concurrent task starting to log the directory not see the
update and therefore can log the directory after we removed a child
directory which had a snapshot within instead of falling back to a
transaction commit. Replaying such a log tree would result in a mount
failure since we can't currently delete snapshots (and subvolumes) during
log replay. This is the type of failure described in commit 1ec9a1ae1e30
("Btrfs: fix unreplayable log after snapshot delete + parent dir fsync").

Fix this by using btrfs_record_snapshot_destroy() which updates the
last_unlink_trans field while holding the inode's log_mutex lock.

Fixes: 44f714dae50a ("Btrfs: improve performance on fsync against new inode after rename/unlink")
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fs/btrfs/inode.c