summaryrefslogtreecommitdiff
path: root/fs/hfsplus
diff options
context:
space:
mode:
authorErnesto A. Fernández <ernesto.mnd.fernandez@gmail.com>2018-10-31 01:06:17 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-12-01 11:13:54 +0300
commite11318583164ff5ce50fa5ec6c2c7b5360816321 (patch)
tree3231312060cc291baffa577ae0d1345078f7eb2a /fs/hfsplus
parent71db3989910218b45c624473029228a56a82cb88 (diff)
downloadlinux-e11318583164ff5ce50fa5ec6c2c7b5360816321.tar.xz
hfs: prevent btree data loss on ENOSPC
[ Upstream commit 54640c7502e5ed41fbf4eedd499e85f9acc9698f ] Inserting a new record in a btree may require splitting several of its nodes. If we hit ENOSPC halfway through, the new nodes will be left orphaned and their records will be lost. This could mean lost inodes or extents. Henceforth, check the available disk space before making any changes. This still leaves the potential problem of corruption on ENOMEM. There is no need to reserve space before deleting a catalog record, as we do for hfsplus. This difference is because hfs index nodes have fixed length keys. Link: http://lkml.kernel.org/r/ab5fc8a7d5ffccfd5f27b1cf2cb4ceb6c110da74.1536269131.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'fs/hfsplus')
0 files changed, 0 insertions, 0 deletions