From: Dave Chinner <david@fromorbit.com>
To: Chandan Babu R <chandan.babu@oracle.com>
Cc: linux-xfs@vger.kernel.org, djwong@kernel.org,
Dave Chinner <dchinner@redhat.com>
Subject: Re: [PATCH V7 12/17] xfs: Introduce per-inode 64-bit extent counters
Date: Fri, 4 Mar 2022 18:14:27 +1100 [thread overview]
Message-ID: <20220304071427.GH59715@dread.disaster.area> (raw)
In-Reply-To: <20220301103938.1106808-13-chandan.babu@oracle.com>
On Tue, Mar 01, 2022 at 04:09:33PM +0530, Chandan Babu R wrote:
> This commit introduces new fields in the on-disk inode format to support
> 64-bit data fork extent counters and 32-bit attribute fork extent
> counters. The new fields will be used only when an inode has
> XFS_DIFLAG2_NREXT64 flag set. Otherwise we continue to use the regular 32-bit
> data fork extent counters and 16-bit attribute fork extent counters.
>
> Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
> Suggested-by: Dave Chinner <dchinner@redhat.com>
> ---
> fs/xfs/libxfs/xfs_format.h | 33 ++++++++++++--
> fs/xfs/libxfs/xfs_inode_buf.c | 49 ++++++++++++++++++--
> fs/xfs/libxfs/xfs_inode_fork.h | 6 +++
> fs/xfs/libxfs/xfs_log_format.h | 33 ++++++++++++--
> fs/xfs/xfs_inode_item.c | 23 ++++++++--
> fs/xfs/xfs_inode_item_recover.c | 79 ++++++++++++++++++++++++++++-----
> 6 files changed, 196 insertions(+), 27 deletions(-)
.....
> +static xfs_failaddr_t
> +xfs_dinode_verify_nrext64(
> + struct xfs_mount *mp,
> + struct xfs_dinode *dip)
> +{
> + if (xfs_dinode_has_nrext64(dip)) {
> + if (!xfs_has_nrext64(mp))
> + return __this_address;
> + if (dip->di_nrext64_pad != 0)
> + return __this_address;
> + } else if (dip->di_version >= 3) {
> + if (dip->di_v3_pad != 0)
> + return __this_address;
> + }
> +
> + return NULL;
> +}
Shouldn't this also check that di_v2_pad is zero if it's a v2 inode?
Also, this isn't verifying the actual extent count range. Maybe
that's done somewhere else now, and if so, shouldn't we move all the
extent count verification checks into a single function called,
say, xfs_dinode_verify_extent_counts()?
> @@ -348,21 +366,60 @@ xlog_recover_inode_commit_pass2(
> goto out_release;
> }
> }
> - if (unlikely(ldip->di_nextents + ldip->di_anextents > ldip->di_nblocks)){
> - XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(5)",
> +
> + if (xfs_log_dinode_has_nrext64(ldip)) {
> + if (!xfs_has_nrext64(mp) || (ldip->di_nrext64_pad != 0)) {
> + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(5)",
Can we have a meaningful error like "Bad log dinode large extent
count format" rather than something we have to go look up the source
code to understand when someone reports a problem?
> + XFS_ERRLEVEL_LOW, mp, ldip,
> + sizeof(*ldip));
> + xfs_alert(mp,
> + "%s: Bad inode log record, rec ptr "PTR_FMT", "
> + "dino ptr "PTR_FMT", dino bp "PTR_FMT", "
> + "ino %Ld, xfs_has_nrext64(mp) = %d, "
> + "ldip->di_nrext64_pad = %u",
What's the point of printing pointers here? Just print the inode
number and the bad values - we log the pointers in the
the log recovery tracepoints so there's no need to print them in
user facing errors because we can't do anything with them without a
debugger attached.
Hence we really only need to dump the inode number and the bad extent
format information - we already have the error context/location from
the corruption error report above. Hence all we need here is:
xfs_alert(mp,
"Bad inode 0x%llx, nrext64 %d, padding 0x%x"
in_f->ilf_ino, xfs_has_nrext64(mp).
ldip->di_nrext64_pad);
The other new alerts can be cleaned up like this, too.
> + __func__, item, dip, bp, in_f->ilf_ino,
> + xfs_has_nrext64(mp), ldip->di_nrext64_pad);
> + error = -EFSCORRUPTED;
> + goto out_release;
> + }
> + } else {
> + if (ldip->di_version == 3 && ldip->di_big_nextents != 0) {
> + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(6)",
> + XFS_ERRLEVEL_LOW, mp, ldip,
> + sizeof(*ldip));
> + xfs_alert(mp,
> + "%s: Bad inode log record, rec ptr "PTR_FMT", "
> + "dino ptr "PTR_FMT", dino bp "PTR_FMT", "
> + "ino %Ld, ldip->di_big_dextcnt = %llu",
> + __func__, item, dip, bp, in_f->ilf_ino,
> + ldip->di_big_nextents);
> + error = -EFSCORRUPTED;
> + goto out_release;
> + }
> + }
> +
> + if (xfs_log_dinode_has_nrext64(ldip)) {
> + nextents = ldip->di_big_nextents;
> + anextents = ldip->di_big_anextents;
> + } else {
> + nextents = ldip->di_nextents;
> + anextents = ldip->di_anextents;
> + }
Also, this can be put in the above if statements, it does not need
a separate identical if clause.
> +
> + if (unlikely(nextents + anextents > ldip->di_nblocks)) {
> + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(7)",
> XFS_ERRLEVEL_LOW, mp, ldip,
> sizeof(*ldip));
> xfs_alert(mp,
> "%s: Bad inode log record, rec ptr "PTR_FMT", dino ptr "PTR_FMT", "
> - "dino bp "PTR_FMT", ino %Ld, total extents = %d, nblocks = %Ld",
> + "dino bp "PTR_FMT", ino %Ld, total extents = %llu, nblocks = %Ld",
> __func__, item, dip, bp, in_f->ilf_ino,
> - ldip->di_nextents + ldip->di_anextents,
> - ldip->di_nblocks);
> + nextents + anextents, ldip->di_nblocks);
> error = -EFSCORRUPTED;
> goto out_release;
> }
ALso, I think that xlog_recover_inode_commit_pass2() is already too
big without adding this new verification to it. Can we factor this
into a separate function (say xlog_dinode_verify_extent_counts())
> if (unlikely(ldip->di_forkoff > mp->m_sb.sb_inodesize)) {
> - XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(6)",
> + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(8)",
> XFS_ERRLEVEL_LOW, mp, ldip,
> sizeof(*ldip));
> xfs_alert(mp,
> @@ -374,7 +431,7 @@ xlog_recover_inode_commit_pass2(
> }
> isize = xfs_log_dinode_size(mp);
> if (unlikely(item->ri_buf[1].i_len > isize)) {
> - XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(7)",
> + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(9)",
> XFS_ERRLEVEL_LOW, mp, ldip,
> sizeof(*ldip));
> xfs_alert(mp,
And this is exactly why I don't like these numbered warnings. Make
the warning descriptive rather than numbered -
changing/adding/removing a warning shouldn't force us to change a
bunch of unrelated warninngs...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2022-03-04 7:15 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 10:39 [PATCH V7 00/17] xfs: Extend per-inode extent counters Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 01/17] xfs: Move extent count limits to xfs_format.h Chandan Babu R
2022-03-04 0:55 ` Dave Chinner
2022-03-01 10:39 ` [PATCH V7 02/17] xfs: Introduce xfs_iext_max_nextents() helper Chandan Babu R
2022-03-04 0:56 ` Dave Chinner
2022-03-01 10:39 ` [PATCH V7 03/17] xfs: Use xfs_extnum_t instead of basic data types Chandan Babu R
2022-03-04 0:59 ` Dave Chinner
2022-03-04 1:30 ` Dave Chinner
2022-03-01 10:39 ` [PATCH V7 04/17] xfs: Introduce xfs_dfork_nextents() helper Chandan Babu R
2022-03-04 1:43 ` Dave Chinner
2022-03-05 12:42 ` Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 05/17] xfs: Use basic types to define xfs_log_dinode's di_nextents and di_anextents Chandan Babu R
2022-03-04 1:44 ` Dave Chinner
2022-03-01 10:39 ` [PATCH V7 06/17] xfs: Promote xfs_extnum_t and xfs_aextnum_t to 64 and 32-bits respectively Chandan Babu R
2022-03-04 1:29 ` Dave Chinner
2022-03-05 12:43 ` Chandan Babu R
2022-03-07 4:55 ` Dave Chinner
2022-03-01 10:39 ` [PATCH V7 07/17] xfs: Introduce XFS_SB_FEAT_INCOMPAT_NREXT64 and associated per-fs feature bit Chandan Babu R
2022-03-04 1:57 ` Dave Chinner
2022-03-05 12:43 ` Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 08/17] xfs: Introduce XFS_FSOP_GEOM_FLAGS_NREXT64 Chandan Babu R
2022-03-04 1:58 ` Dave Chinner
2022-03-01 10:39 ` [PATCH V7 09/17] xfs: Introduce XFS_DIFLAG2_NREXT64 and associated helpers Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 10/17] xfs: Use xfs_rfsblock_t to count maximum blocks that can be used by BMBT Chandan Babu R
2022-03-04 2:09 ` Dave Chinner
2022-03-05 12:44 ` Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 11/17] xfs: Introduce macros to represent new maximum extent counts for data/attr forks Chandan Babu R
2022-03-04 2:32 ` Dave Chinner
2022-03-05 12:44 ` Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 12/17] xfs: Introduce per-inode 64-bit extent counters Chandan Babu R
2022-03-04 7:14 ` Dave Chinner [this message]
2022-03-05 12:44 ` Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 13/17] xfs: xfs_growfs_rt_alloc: Unlock inode explicitly rather than through iop_committing() Chandan Babu R
2022-03-02 0:26 ` Darrick J. Wong
2022-03-04 7:25 ` Dave Chinner
2022-03-05 12:44 ` Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 14/17] xfs: Conditionally upgrade existing inodes to use 64-bit extent counters Chandan Babu R
2022-03-04 7:51 ` Dave Chinner
2022-03-05 12:45 ` Chandan Babu R
2022-03-07 5:02 ` Dave Chinner
2022-03-07 10:20 ` Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 15/17] xfs: Enable bulkstat ioctl to support 64-bit per-inode " Chandan Babu R
2022-03-02 0:31 ` Darrick J. Wong
2022-03-04 8:09 ` Dave Chinner
2022-03-05 12:45 ` Chandan Babu R
2022-03-07 5:13 ` Dave Chinner
2022-03-07 13:46 ` Chandan Babu R
2022-03-07 21:41 ` Dave Chinner
2022-03-08 2:52 ` Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 16/17] xfs: Add XFS_SB_FEAT_INCOMPAT_NREXT64 to the list of supported flags Chandan Babu R
2022-03-01 10:39 ` [PATCH V7 17/17] xfs: Define max extent length based on on-disk format definition Chandan Babu R
2022-03-04 8:15 ` Dave Chinner
2022-03-05 12:45 ` Chandan Babu R
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=20220304071427.GH59715@dread.disaster.area \
--to=david@fromorbit.com \
--cc=chandan.babu@oracle.com \
--cc=dchinner@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