linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).