Archive-only list for patches
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christian Brauner <brauner@kernel.org>,
	Chandan Babu R <chandan.babu@oracle.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Pankaj Raghav <p.raghav@samsung.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Dave Chinner <dchinner@redhat.com>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	patches@lists.linux.dev
Subject: Re: [PATCH] xfs: Fix format specifier for max_folio_size in xfs_fs_fill_super()
Date: Thu, 29 Aug 2024 10:50:15 -0700	[thread overview]
Message-ID: <20240829175015.GA3059476@thelio-3990X> (raw)
In-Reply-To: <Zs_vIaw8ESLN2TwY@casper.infradead.org>

On Thu, Aug 29, 2024 at 04:46:41AM +0100, Matthew Wilcox wrote:
> On Tue, Aug 27, 2024 at 04:15:05PM -0700, Nathan Chancellor wrote:
> > When building for a 32-bit architecture, where 'size_t' is 'unsigned
> > int', there is a warning due to use of '%ld', the specifier for a 'long
> > int':
> > 
> >   In file included from fs/xfs/xfs_linux.h:82,
> >                    from fs/xfs/xfs.h:26,
> >                    from fs/xfs/xfs_super.c:7:
> >   fs/xfs/xfs_super.c: In function 'xfs_fs_fill_super':
> >   fs/xfs/xfs_super.c:1654:1: error: format '%ld' expects argument of type 'long int', but argument 5 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
> >    1654 | "block size (%u bytes) not supported; Only block size (%ld) or less is supported",
> >         | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >    1655 |                                 mp->m_sb.sb_blocksize, max_folio_size);
> >         |                                                        ~~~~~~~~~~~~~~
> >         |                                                        |
> >         |                                                        size_t {aka unsigned int}
> >   ...
> >   fs/xfs/xfs_super.c:1654:58: note: format string is defined here
> >    1654 | "block size (%u bytes) not supported; Only block size (%ld) or less is supported",
> >         |                                                        ~~^
> >         |                                                          |
> >         |                                                          long int
> >         |                                                        %d
> 
> Do we really need the incredibly verbose compiler warning messages?
> Can't we just say "this is the wrong format specifier on 32 bit"
> and be done with it?

Sure, I could have been less verbose. I seem to recall maintainers
desiring the full compiler output at times so that it is easier to see
what the issue is and how the patch fixes the warning but obviously that
is going to vary from maintainer to maintainer. I can send a v2 with
that trimmed if desired or Christian could just axe it when applying if
he really cares? I guess squashing this into the original change would
make this irrelevant too.

> > Use the proper 'size_t' specifier, '%zu', to resolve the warning.
> > 
> > Fixes: 0ab3ca31b012 ("xfs: enable block size larger than page size support")
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> >  fs/xfs/xfs_super.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> > index 242271298a33..e8cc7900911e 100644
> > --- a/fs/xfs/xfs_super.c
> > +++ b/fs/xfs/xfs_super.c
> > @@ -1651,7 +1651,7 @@ xfs_fs_fill_super(
> >  
> >  		if (mp->m_sb.sb_blocksize > max_folio_size) {
> >  			xfs_warn(mp,
> > -"block size (%u bytes) not supported; Only block size (%ld) or less is supported",
> > +"block size (%u bytes) not supported; Only block size (%zu) or less is supported",
> >  				mp->m_sb.sb_blocksize, max_folio_size);
> >  			error = -ENOSYS;
> >  			goto out_free_sb;
> > 
> > ---
> > base-commit: f143d1a48d6ecce12f5bced0d18a10a0294726b5
> > change-id: 20240827-xfs-fix-wformat-bs-gt-ps-967f3aa1c142
> > 
> > Best regards,
> > -- 
> > Nathan Chancellor <nathan@kernel.org>
> > 
> > 

  parent reply	other threads:[~2024-08-29 17:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27 23:15 [PATCH] xfs: Fix format specifier for max_folio_size in xfs_fs_fill_super() Nathan Chancellor
2024-08-27 23:47 ` Darrick J. Wong
2024-08-28 10:23 ` Pankaj Raghav (Samsung)
2024-08-28 21:26 ` Luis Chamberlain
2024-08-29  3:46 ` Matthew Wilcox
2024-08-29  5:20   ` Darrick J. Wong
2024-08-29 17:50   ` Nathan Chancellor [this message]
2024-09-03 13:02 ` Christian Brauner

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=20240829175015.GA3059476@thelio-3990X \
    --to=nathan@kernel.org \
    --cc=brauner@kernel.org \
    --cc=chandan.babu@oracle.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=p.raghav@samsung.com \
    --cc=patches@lists.linux.dev \
    --cc=willy@infradead.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