When building for a 32-bit architecture, for which 'size_t' is
'unsigned int', there is a compiler warning due to use of '%lu':
In file included from fs/bcachefs/vstructs.h:5,
from fs/bcachefs/bcachefs_format.h:80,
from fs/bcachefs/bcachefs.h:207,
from fs/bcachefs/btree_key_cache.c:3:
fs/bcachefs/btree_key_cache.c: In function 'bch2_btree_key_cache_to_text':
fs/bcachefs/btree_key_cache.c:795:25: error: format '%lu' expects argument of
type 'long unsigned int', but argument 3 has type 'size_t' {aka 'unsigned int'}
[-Werror=format=]
795 | prt_printf(out, "pending:\t%lu\r\n",
per_cpu_sum(bc->nr_pending));
| ^~~~~~~~~~~~~~~~~~~
fs/bcachefs/util.h:78:63: note: in definition of macro 'prt_printf'
78 | #define prt_printf(_out, ...) bch2_prt_printf(_out,
__VA_ARGS__)
|
^~~~~~~~~~~
fs/bcachefs/btree_key_cache.c:795:38: note: format string is defined here
795 | prt_printf(out, "pending:\t%lu\r\n",
per_cpu_sum(bc->nr_pending));
| ~~^
| |
| long unsigned int
| %u
cc1: all warnings being treated as errors
Use the proper specifier, '%zu', to resolve the warning.
Fixes: e447e49977b8 ("bcachefs: key cache can now allocate from pending")
Signed-off-by: Nathan Chancellor <[email protected]>
---
fs/bcachefs/btree_key_cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/bcachefs/btree_key_cache.c b/fs/bcachefs/btree_key_cache.c
index caddda160a23..5f479cb8ae5a 100644
--- a/fs/bcachefs/btree_key_cache.c
+++ b/fs/bcachefs/btree_key_cache.c
@@ -792,7 +792,7 @@ void bch2_btree_key_cache_to_text(struct printbuf *out,
struct btree_key_cache *
prt_printf(out, "skipped_accessed:\t%lu\r\n", bc->skipped_accessed);
prt_printf(out, "skipped_lock_fail:\t%lu\r\n", bc->skipped_lock_fail);
prt_newline(out);
- prt_printf(out, "pending:\t%lu\r\n",
per_cpu_sum(bc->nr_pending));
+ prt_printf(out, "pending:\t%zu\r\n",
per_cpu_sum(bc->nr_pending));
}
void bch2_btree_key_cache_exit(void)
---
base-commit: 8ff69508bbd974755240b30307fc95904cb8c17d
change-id: 20240821-bch2_btree_key_cache_to_text-fix-specifier-601c6d8921ab
Best regards,
--
Nathan Chancellor <[email protected]>
