From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/3] xfs_db: stop misusing an onstack inode
Date: Mon, 10 Aug 2020 13:00:19 -0700 [thread overview]
Message-ID: <20200810200019.GF6096@magnolia> (raw)
In-Reply-To: <20200715183849.GA22039@infradead.org>
On Wed, Jul 15, 2020 at 07:38:49PM +0100, Christoph Hellwig wrote:
> On Tue, Jul 14, 2020 at 02:46:43PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > The onstack inode in xfs_check's process_inode is a potential landmine
> > since it's not a /real/ incore inode. The upcoming 5.8 merge will make
> > this messier wrt inode forks, so just remove the onstack inode and
> > reference the ondisk fields directly. This also reduces the amount of
> > thinking that I have to do w.r.t. future libxfs porting efforts.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
>
> Comparing this to my version here:
>
> http://git.infradead.org/users/hch/xfsprogs.git/commitdiff/791d7d324290dbb83be7bf35fe15f9898f5df1c1
>
> > mode_t mode;
> > + uint16_t diflags;
> > + uint64_t diflags2 = 0;
<shrug> I'd rather just leave these over cluttering up the function with
repeated flags/flags2 endian conversions.
> > + xfs_nlink_t nlink;
Actually, we do need this one for proper error reporting because we
still (sort of) have to have v1 disk format support. For that matter,
the nlink checking further in that function looks totally wrong; it
should be using nlink and not accessing the raw field directly.
> > + xfs_dqid_t uid;
> > + xfs_dqid_t gid;
> > + xfs_dqid_t prid;
These actually are needed, because the quota_add function that uses them
requires pointers to xfs_dqid_t to do some hazy magic to skip quota
accounting if the pointer is null, which implies local variables since
the ondisk inode has be32 values...
That whole thing is messy (and gets worse with the project id) but I'd
rather not go rearchitecting more of db/check.c seeing as we can
probably just kill it after xfsprogs 5.8 releases.
> Not sure we really need the local variables, as they are mostly just
> used once except for error messages..
>
> > + if (dip->di_version == 1) {
> > + nlink = be16_to_cpu(dip->di_onlink);
> > + prid = 0;
> > + } else {
> > + nlink = be32_to_cpu(dip->di_nlink);
> > + prid = (xfs_dqid_t)be16_to_cpu(dip->di_projid_hi) << 16 |
> > + be16_to_cpu(dip->di_projid_lo);
> > + }
>
> I mad the assumption that we don't support v1 inodes anymore, but
> it appears we actually do. So we might need to keep these two.
<nod>
> > if (isfree) {
> > - if (xino.i_d.di_nblocks != 0) {
> > + if (be64_to_cpu(dip->di_nblocks) != 0) {
>
> No need to byte swap for a comparism with 0.
>
> > - if ((unsigned int)xino.i_d.di_aformat > XFS_DINODE_FMT_BTREE) {
> > + if ((unsigned int)dip->di_aformat > XFS_DINODE_FMT_BTREE) {
>
> No need for the (pre-existing) cast here.
>
> > + fmtnames[(int)dip->di_aformat],
Fixed all of these.
--D
>
> Same here.
next prev parent reply other threads:[~2020-08-10 20:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 21:46 [PATCH 0/3] xfs: preparation for syncing with 5.8 Darrick J. Wong
2020-07-14 21:46 ` [PATCH 1/3] xfs_db: stop misusing an onstack inode Darrick J. Wong
2020-07-15 18:38 ` Christoph Hellwig
2020-08-10 20:00 ` Darrick J. Wong [this message]
2020-08-10 23:21 ` Eric Sandeen
2020-07-14 21:46 ` [PATCH 2/3] xfs_repair: never zero a shortform '..' entry Darrick J. Wong
2020-07-15 18:44 ` Christoph Hellwig
2020-07-14 21:46 ` [PATCH 3/3] libxfs: remove ifork_ops from all client programs 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=20200810200019.GF6096@magnolia \
--to=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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;
as well as URLs for NNTP newsgroup(s).