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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.