]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs: fix realtime file data space leak
authorOmar Sandoval <osandov@fb.com>
Wed, 22 Jan 2020 16:29:46 +0000 (11:29 -0500)
committerEric Sandeen <sandeen@redhat.com>
Wed, 22 Jan 2020 16:29:46 +0000 (11:29 -0500)
commitf8446e51caf838e19d88819f0aefb6ec7f1b15bd
tree6f32f38bb1d15231f41c2d78f67db50b8b8b14e6
parentc1d1974473daf6ea1ff68f6665c6fb3226b37da9
xfs: fix realtime file data space leak

Source kernel commit: 0c4da70c83d41a8461fdf50a3f7b292ecb04e378

Realtime files in XFS allocate extents in rextsize units. However, the
written/unwritten state of those extents is still tracked in blocksize
units. Therefore, a realtime file can be split up into written and
unwritten extents that are not necessarily aligned to the realtime
extent size. __xfs_bunmapi() has some logic to handle these various
corner cases. Consider how it handles the following case:

1. The last extent is unwritten.
2. The last extent is smaller than the realtime extent size.
3. startblock of the last extent is not aligned to the realtime extent
size, but startblock + blockcount is.

In this case, __xfs_bunmapi() calls xfs_bmap_add_extent_unwritten_real()
to set the second-to-last extent to unwritten. This should merge the
last and second-to-last extents, so __xfs_bunmapi() moves on to the
second-to-last extent.

However, if the size of the last and second-to-last extents combined is
greater than MAXEXTLEN, xfs_bmap_add_extent_unwritten_real() does not
merge the two extents. When that happens, __xfs_bunmapi() skips past the
last extent without unmapping it, thus leaking the space.

Fix it by only unwriting the minimum amount needed to align the last
extent to the realtime extent size, which is guaranteed to merge with
the last extent.

Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
include/platform_defs.h.in
libxfs/xfs_bmap.c