public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Eric Sandeen <sandeen@redhat.com>, xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] misc: fix more stupid compiler warnings
Date: Sun, 3 Sep 2017 17:22:35 -0700	[thread overview]
Message-ID: <20170904002235.GB4671@magnolia> (raw)
In-Reply-To: <20170903072432.GA32095@infradead.org>

On Sun, Sep 03, 2017 at 12:24:33AM -0700, Christoph Hellwig wrote:
> Can you splits this up a bit to be more self explanatory, e.g.
> one patch per warning class or logical change?
> 
> >  	if (be32_to_cpu(free->hdr.nvalid) > maxent ||
> > -				be32_to_cpu(free->hdr.nvalid) < 0 ||
> >  				be32_to_cpu(free->hdr.nused) > maxent ||
> > -				be32_to_cpu(free->hdr.nused) < 0 ||
> >  				be32_to_cpu(free->hdr.nused) >
> >  					be32_to_cpu(free->hdr.nvalid)) {
> 
> be32_to_cpu returns uint, so this makese sense.
> 
> > -	(void)getcwd(curdir,MAXPATHLEN);
> > +	if (!getcwd(curdir, MAXPATHLEN)) {
> > +		perror("getcwd");
> > +		strcpy(curdir, ".");
> > +	}
> 
> All this chdir magic will need a lot more explanation.  To me it
> seems like most of this is a left over from IRIX days where we
> could have device names relative to a volume.  The proper fix
> probably is to just remove that whole thing - if we'd ever
> need to bring it back we should use openat relative to a dirfd
> instead.

Yeah, AFAICT all this getcwd/chdir stuff seems to exist so that
check_open can change the working directory (it doesn't on Linux) and we
can change back to continue to use relative paths.  Nothing ever changes
the directory (at least not in the call paths of libxfs_init) so I think
we can just rip it out.  As a separate patch.

In the meantime, do you want me to resend with just the uncontroversial
bits?

--D

> > +#define xfs_inode_set_cowblocks_tag(ip)	do { } while (0)
> > +#define xfs_inode_set_eofblocks_tag(ip)	do { } while (0)
> 
> This part looks fine.
> 
> >  #else
> >  #define xfs_bmap_check_leaf_extents(cur, ip, whichfork)		do { } while (0)
> > -#define	xfs_bmap_validate_ret(bno,len,flags,mval,onmap,nmap)
> > +#define	xfs_bmap_validate_ret(bno,len,flags,mval,onmap,nmap)	do { } while (0)
> >  #endif /* DEBUG */
> 
> This as well.
> 
> > diff --git a/repair/phase6.c b/repair/phase6.c
> > index b051a44..f360aed 100644
> > --- a/repair/phase6.c
> > +++ b/repair/phase6.c
> > @@ -3092,11 +3092,11 @@ mark_standalone_inodes(xfs_mount_t *mp)
> >  	irec = find_inode_rec(mp, XFS_INO_TO_AGNO(mp, mp->m_sb.sb_rsumino),
> >  			XFS_INO_TO_AGINO(mp, mp->m_sb.sb_rsumino));
> >  
> > +	ASSERT(irec != NULL);
> > +
> >  	offset = XFS_INO_TO_AGINO(mp, mp->m_sb.sb_rsumino) -
> >  			irec->ino_startnum;
> >  
> > -	ASSERT(irec != NULL);
> > -
> 
> What's the point in even having this assert?   Either we turn this
> into something like
> 
> 	if (!irec)
> 		abort();
> 
> or just let the code dereference it.
> 
> > -		imap.br_state = (rm_rec->rm_flags & XFS_RMAP_UNWRITTEN ?
> > +		imap.br_state = ((rm_rec->rm_flags & XFS_RMAP_UNWRITTEN) ?
> >  				XFS_EXT_UNWRITTEN : XFS_EXT_NORM);
> 
> Looks fine.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-09-04  0:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-01 22:21 [PATCH] misc: fix more stupid compiler warnings Darrick J. Wong
2017-09-03  3:41 ` Eric Sandeen
2017-09-03  7:24 ` Christoph Hellwig
2017-09-04  0:22   ` Darrick J. Wong [this message]
2017-09-04  1:01     ` Eric Sandeen

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=20170904002235.GB4671@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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