[next,1/2] btrfs: tree-checker: Fix error format string
diff mbox series

Message ID 20191108213853.16635-2-afaerber@suse.de
State New
Headers show
Series
  • btrfs: Fix build warnings for arm
Related show

Commit Message

Andreas Färber Nov. 8, 2019, 9:38 p.m. UTC
From: Andreas Färber <afaerber@suse.com>

Argument BTRFS_FILE_EXTENT_INLINE_DATA_START is defined as offsetof(),
which returns type size_t, so we need %zu instead of %lu.

This fixes a build warning on 32-bit arm:

  ../fs/btrfs/tree-checker.c: In function 'check_extent_data_item':
  ../fs/btrfs/tree-checker.c:230:43: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Wformat=]
    230 |     "invalid item size, have %u expect [%lu, %u)",
        |                                         ~~^
        |                                           |
        |                                           long unsigned int
        |                                         %u

Fixes: a31ccb4b7ba2 ("btrfs: tree-checker: Check item size before reading file extent type")
Cc: Qu Wenruo <wqu@suse.com>
Cc: David Sterba <dsterba@suse.com>
Signed-off-by: Andreas Färber <afaerber@suse.com>
---
 fs/btrfs/tree-checker.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

David Sterba Nov. 11, 2019, 6:31 p.m. UTC | #1
On Fri, Nov 08, 2019 at 10:38:52PM +0100, Andreas Färber wrote:
> From: Andreas Färber <afaerber@suse.com>
> 
> Argument BTRFS_FILE_EXTENT_INLINE_DATA_START is defined as offsetof(),
> which returns type size_t, so we need %zu instead of %lu.
> 
> This fixes a build warning on 32-bit arm:
> 
>   ../fs/btrfs/tree-checker.c: In function 'check_extent_data_item':
>   ../fs/btrfs/tree-checker.c:230:43: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Wformat=]
>     230 |     "invalid item size, have %u expect [%lu, %u)",
>         |                                         ~~^
>         |                                           |
>         |                                           long unsigned int
>         |                                         %u

Is there a gcc warning option that can catch that on 64bit too?
-Wformat=2 does not and I don't see any other of the option family to do
that. We've had fixups of the size_t printk formats and I'd like to
catch that when the patches are added to the devel branches. I can't run
32bit build check each time but this seems to be the only way so far.

> Fixes: a31ccb4b7ba2 ("btrfs: tree-checker: Check item size before reading file extent type")

As the patch is still in the devel branch, the commit id is not stable
and I'll fold the change to to the patch. Thanks.
Geert Uytterhoeven Nov. 26, 2019, 10:36 a.m. UTC | #2
Hi David,

On Mon, Nov 11, 2019 at 7:32 PM David Sterba <dsterba@suse.cz> wrote:
> On Fri, Nov 08, 2019 at 10:38:52PM +0100, Andreas Färber wrote:
> > From: Andreas Färber <afaerber@suse.com>
> >
> > Argument BTRFS_FILE_EXTENT_INLINE_DATA_START is defined as offsetof(),
> > which returns type size_t, so we need %zu instead of %lu.
> >
> > This fixes a build warning on 32-bit arm:
> >
> >   ../fs/btrfs/tree-checker.c: In function 'check_extent_data_item':
> >   ../fs/btrfs/tree-checker.c:230:43: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Wformat=]
> >     230 |     "invalid item size, have %u expect [%lu, %u)",
> >         |                                         ~~^
> >         |                                           |
> >         |                                           long unsigned int
> >         |                                         %u
>
> Is there a gcc warning option that can catch that on 64bit too?
> -Wformat=2 does not and I don't see any other of the option family to do
> that. We've had fixups of the size_t printk formats and I'd like to
> catch that when the patches are added to the devel branches. I can't run
> 32bit build check each time but this seems to be the only way so far.

Yep. On 64-bit, size_t _is_ unsigned long.
So you have to compile for both 32-bit and 64-bit.

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

> > Fixes: a31ccb4b7ba2 ("btrfs: tree-checker: Check item size before reading file extent type")
>
> As the patch is still in the devel branch, the commit id is not stable

It indeed is not:
Fixes: 153a6d299956983d ("btrfs: tree-checker: Check item size before
reading file extent type")

> and I'll fold the change to to the patch. Thanks.

Apparently that was forgotten, and now the issue is part of Linus' tree.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
David Sterba Nov. 26, 2019, 3:44 p.m. UTC | #3
On Tue, Nov 26, 2019 at 11:36:58AM +0100, Geert Uytterhoeven wrote:
> > > Fixes: a31ccb4b7ba2 ("btrfs: tree-checker: Check item size before reading file extent type")
> >
> > As the patch is still in the devel branch, the commit id is not stable
> 
> It indeed is not:
> Fixes: 153a6d299956983d ("btrfs: tree-checker: Check item size before
> reading file extent type")
> 
> > and I'll fold the change to to the patch. Thanks.
> 
> Apparently that was forgotten, and now the issue is part of Linus' tree.

Mistake on my side so I'll apply the full fixup patch, thanks for
noticing.

Patch
diff mbox series

diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index 493d4d9e0f79..092b8ece36d7 100644
--- a/fs/btrfs/tree-checker.c
+++ b/fs/btrfs/tree-checker.c
@@ -227,7 +227,7 @@  static int check_extent_data_item(struct extent_buffer *leaf,
 	 */
 	if (item_size < BTRFS_FILE_EXTENT_INLINE_DATA_START) {
 		file_extent_err(leaf, slot,
-				"invalid item size, have %u expect [%lu, %u)",
+				"invalid item size, have %u expect [%zu, %u)",
 				item_size, BTRFS_FILE_EXTENT_INLINE_DATA_START,
 				SZ_4K);
 		return -EUCLEAN;