From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org, bfoster@redhat.com
Subject: Re: [PATCH 2/2] xfs: validate extsz hints against rt extent size when rtinherit is set
Date: Fri, 21 May 2021 08:49:03 +0100 [thread overview]
Message-ID: <YKdl75i5ORTiJqlO@infradead.org> (raw)
In-Reply-To: <162152894725.2694219.2966158387963381824.stgit@magnolia>
On Thu, May 20, 2021 at 09:42:27AM -0700, Darrick J. Wong wrote:
> diff --git a/fs/xfs/libxfs/xfs_inode_buf.c b/fs/xfs/libxfs/xfs_inode_buf.c
> index 045118c7bf78..dce267dbea5f 100644
> --- a/fs/xfs/libxfs/xfs_inode_buf.c
> +++ b/fs/xfs/libxfs/xfs_inode_buf.c
> @@ -589,8 +589,21 @@ xfs_inode_validate_extsize(
> inherit_flag = (flags & XFS_DIFLAG_EXTSZINHERIT);
> extsize_bytes = XFS_FSB_TO_B(mp, extsize);
>
> + /*
> + * Historically, XFS didn't check that the extent size hint was an
> + * integer multiple of the rt extent size on a directory with both
> + * rtinherit and extszinherit flags set. This results in math errors
> + * in the rt allocator and inode verifier errors when the unaligned
> + * hint value propagates into new realtime files. Since there might
> + * be filesystems in the wild, the best we can do for now is to
> + * mitigate the harms by stopping the propagation.
> + *
> + * The next time we add a new inode feature, the if test below should
> + * also trigger if that new feature is enabled and (rtinherit_flag &&
> + * inherit_flag).
> + */
I don't understand how this comment relates to the change below, and
in fact I don't understand the last paragraph at all.
> if (rt_flag)
> - blocksize_bytes = mp->m_sb.sb_rextsize << mp->m_sb.sb_blocklog;
> + blocksize_bytes = XFS_FSB_TO_B(mp, mp->m_sb.sb_rextsize);
This just looks like a cleanup, that is replace the open coded version
of XFS_FSB_TO_B with the actual helper.
> + /*
> + * Clear invalid extent size hints set on files with rtinherit and
> + * extszinherit set. See the comments in xfs_inode_validate_extsize
> + * for details.
> + */
Maybe that comment should be here as it makes a whole lot more sense
where we do the actual clearing.
> + if ((ip->i_diflags & XFS_DIFLAG_RTINHERIT) &&
> + (ip->i_diflags & XFS_DIFLAG_EXTSZINHERIT) &&
> + (ip->i_extsize % ip->i_mount->m_sb.sb_rextsize) > 0) {
> + ip->i_diflags &= ~(XFS_DIFLAG_EXTSIZE | XFS_DIFLAG_EXTSZINHERIT);
Overly long line.
> + xfs_failaddr_t failaddr;
> umode_t mode = VFS_I(ip)->i_mode;
>
> if (S_ISDIR(mode)) {
> if (pip->i_diflags & XFS_DIFLAG_RTINHERIT)
> - di_flags |= XFS_DIFLAG_RTINHERIT;
> + ip->i_diflags |= XFS_DIFLAG_RTINHERIT;
The removal of the di_flags seems like an unrelated (though nice)
cleanup.
next prev parent reply other threads:[~2021-05-21 7:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 16:42 [PATCHSET v2 0/2] xfs: strengthen validation of extent size hints Darrick J. Wong
2021-05-20 16:42 ` [PATCH 1/2] xfs: standardize extent size hint validation Darrick J. Wong
2021-05-21 7:29 ` Christoph Hellwig
2021-05-20 16:42 ` [PATCH 2/2] xfs: validate extsz hints against rt extent size when rtinherit is set Darrick J. Wong
2021-05-21 7:49 ` Christoph Hellwig [this message]
2021-05-21 19:31 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2021-05-24 1:01 [PATCHSET v2 0/2] xfs: strengthen validation of extent size hints Darrick J. Wong
2021-05-24 1:01 ` [PATCH 2/2] xfs: validate extsz hints against rt extent size when rtinherit is set Darrick J. Wong
2021-05-24 10:42 ` Brian Foster
2021-05-24 17:23 ` Darrick J. Wong
2021-05-24 18:18 ` Darrick J. Wong
2021-05-24 18:21 ` Brian Foster
2021-05-24 21:26 ` Darrick J. Wong
2021-05-24 22:12 ` Darrick J. Wong
2021-05-25 11:53 ` Brian Foster
2021-05-25 18:13 ` 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=YKdl75i5ORTiJqlO@infradead.org \
--to=hch@infradead.org \
--cc=bfoster@redhat.com \
--cc=djwong@kernel.org \
--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