From: "Darrick J. Wong" <djwong@kernel.org>
To: chandanbabu@kernel.org, hch@lst.de
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/3] xfs: don't allow overly small or large realtime volumes
Date: Sun, 3 Dec 2023 11:09:51 -0800 [thread overview]
Message-ID: <20231203190951.GV361584@frogsfrogsfrogs> (raw)
In-Reply-To: <170162990673.3038044.6698602496725473343.stgit@frogsfrogsfrogs>
On Sun, Dec 03, 2023 at 11:05:50AM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
>
> Don't allow realtime volumes that are less than one rt extent long.
> This has been broken across 4 LTS kernels with nobody noticing, so let's
> just disable it.
>
> Per the previous patch, I also observed integer overflows in calculating
> rextslog (the number of rt summary levels) when the rtextent count
> exceeds 2^32. If you're lucky, this means that mkfs will fail to format
> the filesystem; if not, then the fs will go down due to corruption
> errors. Prohibit those too; larger volume support will return with
> rtgroups.
....aaand I forgot to update the commit message on this one, sorry.
Strike the previous paragraph, please.
--D
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
> fs/xfs/libxfs/xfs_rtbitmap.h | 12 ++++++++++++
> fs/xfs/libxfs/xfs_sb.c | 3 ++-
> fs/xfs/xfs_rtalloc.c | 2 ++
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
>
> diff --git a/fs/xfs/libxfs/xfs_rtbitmap.h b/fs/xfs/libxfs/xfs_rtbitmap.h
> index 1610d0e4a04c..411de3b889ae 100644
> --- a/fs/xfs/libxfs/xfs_rtbitmap.h
> +++ b/fs/xfs/libxfs/xfs_rtbitmap.h
> @@ -353,6 +353,18 @@ int xfs_rtfree_blocks(struct xfs_trans *tp, xfs_fsblock_t rtbno,
>
> uint8_t xfs_compute_rextslog(xfs_rtbxlen_t rtextents);
>
> +/* Do we support an rt volume having this number of rtextents? */
> +static inline bool
> +xfs_validate_rtextents(
> + xfs_rtbxlen_t rtextents)
> +{
> + /* No runt rt volumes */
> + if (rtextents == 0)
> + return false;
> +
> + return true;
> +}
> +
> xfs_filblks_t xfs_rtbitmap_blockcount(struct xfs_mount *mp, xfs_rtbxlen_t
> rtextents);
> unsigned long long xfs_rtbitmap_wordcount(struct xfs_mount *mp,
> diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c
> index df12bf82ed18..4a9e8588f4c9 100644
> --- a/fs/xfs/libxfs/xfs_sb.c
> +++ b/fs/xfs/libxfs/xfs_sb.c
> @@ -509,7 +509,8 @@ xfs_validate_sb_common(
> rbmblocks = howmany_64(sbp->sb_rextents,
> NBBY * sbp->sb_blocksize);
>
> - if (sbp->sb_rextents != rexts ||
> + if (!xfs_validate_rtextents(rexts) ||
> + sbp->sb_rextents != rexts ||
> sbp->sb_rextslog != xfs_compute_rextslog(rexts) ||
> sbp->sb_rbmblocks != rbmblocks) {
> xfs_notice(mp,
> diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c
> index 7c5a50163d2d..8feb58c6241c 100644
> --- a/fs/xfs/xfs_rtalloc.c
> +++ b/fs/xfs/xfs_rtalloc.c
> @@ -963,6 +963,8 @@ xfs_growfs_rt(
> */
> nrextents = nrblocks;
> do_div(nrextents, in->extsize);
> + if (!xfs_validate_rtextents(nrextents))
> + return -EINVAL;
> nrbmblocks = xfs_rtbitmap_blockcount(mp, nrextents);
> nrextslog = xfs_compute_rextslog(nrextents);
> nrsumlevels = nrextslog + 1;
>
>
next prev parent reply other threads:[~2023-12-03 19:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-03 19:00 [PATCHSET 0/3] xfs: fix realtime geometry integer overflows Darrick J. Wong
2023-12-03 19:05 ` [PATCH 1/3] xfs: make rextslog computation consistent with mkfs Darrick J. Wong
2023-12-04 4:55 ` Christoph Hellwig
2023-12-04 18:52 ` Darrick J. Wong
2023-12-03 19:05 ` [PATCH 2/3] xfs: fix 32-bit truncation in xfs_compute_rextslog Darrick J. Wong
2023-12-04 4:55 ` Christoph Hellwig
2023-12-03 19:05 ` [PATCH 3/3] xfs: don't allow overly small or large realtime volumes Darrick J. Wong
2023-12-03 19:09 ` Darrick J. Wong [this message]
2023-12-04 4:56 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2023-12-07 2:23 [PATCHSET v2 0/3] xfs: fix realtime geometry integer overflows Darrick J. Wong
2023-12-07 2:28 ` [PATCH 3/3] xfs: don't allow overly small or large realtime volumes Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231203190951.GV361584@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=chandanbabu@kernel.org \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox