Hi Chandan,
Please pull this branch with changes for xfs for 6.8-rc1.
As usual, I did a test-merge with the main upstream branch as of a few
minutes ago, and didn't see any conflicts. Please let me know if you
encounter any problems.
--D
The following changes since commit f0dba2bf31c65d93a6ae3a7e07e765b9e613aa2c:
xfs: move ->iop_relog to struct xfs_defer_op_type (2023-12-06 18:17:24 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git tags/fix-rtmount-overflows-6.8_2023-12-06
for you to fetch changes up to 4d6bd042de601ce29732060101df64725c925836:
xfs: don't allow overly small or large realtime volumes (2023-12-06 18:17:25 -0800)
----------------------------------------------------------------
xfs: fix realtime geometry integer overflows [v2]
While reading through the realtime geometry support code in xfsprogs, I
noticed a discrepancy between the sb_rextslog computation used when
writing out the superblock during mkfs and the validation code used in
xfs_repair. This discrepancy would lead to system failure for a runt rt
volume having more than 1 rt block but zero rt extents in length. Most
people aren't going to configure a 1M extent size for their 360k rt
floppy disk volume, but I did!
In the process of studying that code, it occurred to me that there is a
second bug in the computation -- the use of highbit32 for a 64-bit
value means that the upper 32 bits are not considered in the search for
a high bit. This causes the creation of a realtime summary file that is
the wrong length. If rextents is a multiple of U32_MAX then this will
appear to work fine because highbit32 returns -1 for an input of 0; but
for all other cases the rt summary is undersized, leading to failures.
Fix the first problem by standardizing the computation with a helper in
libxfs; and the second problem by correcting the computation. This will
cause any existing rt volumes larger than 2^32 blocks to fail validation
but they probably were already crashing anyway.
v2: pick up review tags
This has been lightly tested with fstests. Enjoy!
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
----------------------------------------------------------------
Darrick J. Wong (3):
xfs: make rextslog computation consistent with mkfs
xfs: fix 32-bit truncation in xfs_compute_rextslog
xfs: don't allow overly small or large realtime volumes
fs/xfs/libxfs/xfs_rtbitmap.c | 14 ++++++++++++++
fs/xfs/libxfs/xfs_rtbitmap.h | 16 ++++++++++++++++
fs/xfs/libxfs/xfs_sb.c | 6 ++++--
fs/xfs/xfs_rtalloc.c | 6 ++++--
4 files changed, 38 insertions(+), 4 deletions(-)
Hi Chandan, Please pull this branch with changes for xfs for 6.8-rc1. As usual, I did a test-merge with the main upstream branch as of a few minutes ago, and didn't see any conflicts. Please let me know if you encounter any problems. --D The following changes since commit f0dba2bf31c65d93a6ae3a7e07e765b9e613aa2c: xfs: move ->iop_relog to struct xfs_defer_op_type (2023-12-06 18:17:24 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git tags/fix-rtmount-overflows-6.8_2023-12-06 for you to fetch changes up to 4d6bd042de601ce29732060101df64725c925836: xfs: don't allow overly small or large realtime volumes (2023-12-06 18:17:25 -0800) ---------------------------------------------------------------- xfs: fix realtime geometry integer overflows [v2] While reading through the realtime geometry support code in xfsprogs, I noticed a discrepancy between the sb_rextslog computation used when writing out the superblock during mkfs and the validation code used in xfs_repair. This discrepancy would lead to system failure for a runt rt volume having more than 1 rt block but zero rt extents in length. Most people aren't going to configure a 1M extent size for their 360k rt floppy disk volume, but I did! In the process of studying that code, it occurred to me that there is a second bug in the computation -- the use of highbit32 for a 64-bit value means that the upper 32 bits are not considered in the search for a high bit. This causes the creation of a realtime summary file that is the wrong length. If rextents is a multiple of U32_MAX then this will appear to work fine because highbit32 returns -1 for an input of 0; but for all other cases the rt summary is undersized, leading to failures. Fix the first problem by standardizing the computation with a helper in libxfs; and the second problem by correcting the computation. This will cause any existing rt volumes larger than 2^32 blocks to fail validation but they probably were already crashing anyway. v2: pick up review tags This has been lightly tested with fstests. Enjoy! Signed-off-by: Darrick J. Wong <djwong@kernel.org> ---------------------------------------------------------------- Darrick J. Wong (3): xfs: make rextslog computation consistent with mkfs xfs: fix 32-bit truncation in xfs_compute_rextslog xfs: don't allow overly small or large realtime volumes fs/xfs/libxfs/xfs_rtbitmap.c | 14 ++++++++++++++ fs/xfs/libxfs/xfs_rtbitmap.h | 16 ++++++++++++++++ fs/xfs/libxfs/xfs_sb.c | 6 ++++-- fs/xfs/xfs_rtalloc.c | 6 ++++-- 4 files changed, 38 insertions(+), 4 deletions(-)