* Re: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
[not found] <29b7793e53e1cdd559ad212ee69cec211a3b4db2.1704704328.git.wqu@suse.com>
@ 2024-01-09 3:02 ` kernel test robot
2024-01-10 1:59 ` David Sterba
0 siblings, 1 reply; 6+ messages in thread
From: kernel test robot @ 2024-01-09 3:02 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: llvm, oe-kbuild-all
Hi Qu,
kernel test robot noticed the following build warnings:
[auto build test WARNING on kdave/for-next]
[also build test WARNING on next-20240108]
[cannot apply to linus/master v6.7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-zlib-fix-and-simplify-the-inline-extent-decompression/20240108-171206
base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
patch link: https://lore.kernel.org/r/29b7793e53e1cdd559ad212ee69cec211a3b4db2.1704704328.git.wqu%40suse.com
patch subject: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/config)
compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202401091012.pLm6PcKG-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> fs/btrfs/zlib.c:402:15: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
401 | pr_warn_ratelimited("BTRFS: infalte failed, decompressed=%lu expected=%lu\n",
| ~~~
| %zu
402 | to_copy, destlen);
| ^~~~~~~
include/linux/printk.h:665:49: note: expanded from macro 'pr_warn_ratelimited'
665 | printk_ratelimited(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/printk.h:649:17: note: expanded from macro 'printk_ratelimited'
649 | printk(fmt, ##__VA_ARGS__); \
| ~~~ ^~~~~~~~~~~
include/linux/printk.h:455:60: note: expanded from macro 'printk'
455 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/printk.h:427:19: note: expanded from macro 'printk_index_wrap'
427 | _p_func(_fmt, ##__VA_ARGS__); \
| ~~~~ ^~~~~~~~~~~
1 warning generated.
vim +402 fs/btrfs/zlib.c
355
356 int zlib_decompress(struct list_head *ws, const u8 *data_in,
357 struct page *dest_page, unsigned long dest_pgoff, size_t srclen,
358 size_t destlen)
359 {
360 struct workspace *workspace = list_entry(ws, struct workspace, list);
361 int ret = 0;
362 int wbits = MAX_WBITS;
363 unsigned long to_copy;
364
365 workspace->strm.next_in = data_in;
366 workspace->strm.avail_in = srclen;
367 workspace->strm.total_in = 0;
368
369 workspace->strm.next_out = workspace->buf;
370 workspace->strm.avail_out = workspace->buf_size;
371 workspace->strm.total_out = 0;
372 /* If it's deflate, and it's got no preset dictionary, then
373 we can tell zlib to skip the adler32 check. */
374 if (srclen > 2 && !(data_in[1] & PRESET_DICT) &&
375 ((data_in[0] & 0x0f) == Z_DEFLATED) &&
376 !(((data_in[0]<<8) + data_in[1]) % 31)) {
377
378 wbits = -((data_in[0] >> 4) + 8);
379 workspace->strm.next_in += 2;
380 workspace->strm.avail_in -= 2;
381 }
382
383 if (Z_OK != zlib_inflateInit2(&workspace->strm, wbits)) {
384 pr_warn("BTRFS: inflateInit failed\n");
385 return -EIO;
386 }
387
388 /*
389 * Everything (in/out buf) should be at most one sector, there should
390 * be no need to switch any input/output buffer.
391 */
392 ret = zlib_inflate(&workspace->strm, Z_FINISH);
393 to_copy = min(workspace->strm.total_out, destlen);
394 if (ret != Z_STREAM_END)
395 goto out;
396
397 memcpy_to_page(dest_page, dest_pgoff, workspace->buf, to_copy);
398
399 out:
400 if (unlikely(to_copy != destlen)) {
401 pr_warn_ratelimited("BTRFS: infalte failed, decompressed=%lu expected=%lu\n",
> 402 to_copy, destlen);
403 ret = -EIO;
404 } else {
405 ret = 0;
406 }
407
408 zlib_inflateEnd(&workspace->strm);
409
410 if (unlikely(to_copy < destlen))
411 memzero_page(dest_page, dest_pgoff + to_copy, destlen - to_copy);
412 return ret;
413 }
414
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
2024-01-09 3:02 ` [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression kernel test robot
@ 2024-01-10 1:59 ` David Sterba
2024-01-10 2:03 ` Qu Wenruo
0 siblings, 1 reply; 6+ messages in thread
From: David Sterba @ 2024-01-10 1:59 UTC (permalink / raw)
To: kernel test robot; +Cc: Qu Wenruo, linux-btrfs, llvm, oe-kbuild-all
On Tue, Jan 09, 2024 at 11:02:54AM +0800, kernel test robot wrote:
> Hi Qu,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on kdave/for-next]
> [also build test WARNING on next-20240108]
> [cannot apply to linus/master v6.7]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-zlib-fix-and-simplify-the-inline-extent-decompression/20240108-171206
> base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
> patch link: https://lore.kernel.org/r/29b7793e53e1cdd559ad212ee69cec211a3b4db2.1704704328.git.wqu%40suse.com
> patch subject: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
> config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/config)
> compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202401091012.pLm6PcKG-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> >> fs/btrfs/zlib.c:402:15: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
> 401 | pr_warn_ratelimited("BTRFS: infalte failed, decompressed=%lu expected=%lu\n",
> | ~~~
> | %zu
> 402 | to_copy, destlen);
> | ^~~~~~~
Valid report but I can't reproduce it. Built with clang 17 and
explicitly enabled -Wformat. We have additional warnings enabled per
directory fs/btrfs/ so we can add -Wformat, I'd like to know what I'm
missing, we've had fixups for the size_t printk format so it would make
sense to catch it early.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
2024-01-10 1:59 ` David Sterba
@ 2024-01-10 2:03 ` Qu Wenruo
2024-01-10 2:26 ` David Sterba
0 siblings, 1 reply; 6+ messages in thread
From: Qu Wenruo @ 2024-01-10 2:03 UTC (permalink / raw)
To: dsterba, kernel test robot; +Cc: linux-btrfs, llvm, oe-kbuild-all
[-- Attachment #1.1.1: Type: text/plain, Size: 2866 bytes --]
On 2024/1/10 12:29, David Sterba wrote:
> On Tue, Jan 09, 2024 at 11:02:54AM +0800, kernel test robot wrote:
>> Hi Qu,
>>
>> kernel test robot noticed the following build warnings:
>>
>> [auto build test WARNING on kdave/for-next]
>> [also build test WARNING on next-20240108]
>> [cannot apply to linus/master v6.7]
>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>> And when submitting patch, we suggest to use '--base' as documented in
>> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>>
>> url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-zlib-fix-and-simplify-the-inline-extent-decompression/20240108-171206
>> base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
>> patch link: https://lore.kernel.org/r/29b7793e53e1cdd559ad212ee69cec211a3b4db2.1704704328.git.wqu%40suse.com
>> patch subject: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
>> config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/config)
>> compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/reproduce)
>>
>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> the same patch/commit), kindly add following tags
>> | Reported-by: kernel test robot <lkp@intel.com>
>> | Closes: https://lore.kernel.org/oe-kbuild-all/202401091012.pLm6PcKG-lkp@intel.com/
>>
>> All warnings (new ones prefixed by >>):
>>
>>>> fs/btrfs/zlib.c:402:15: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
>> 401 | pr_warn_ratelimited("BTRFS: infalte failed, decompressed=%lu expected=%lu\n",
>> | ~~~
>> | %zu
>> 402 | to_copy, destlen);
>> | ^~~~~~~
>
> Valid report but I can't reproduce it. Built with clang 17 and
> explicitly enabled -Wformat. We have additional warnings enabled per
> directory fs/btrfs/ so we can add -Wformat, I'd like to know what I'm
> missing, we've had fixups for the size_t printk format so it would make
> sense to catch it early.
I guess it's due to the platform? (The report is from 32bit system).
Otherwise it's indeed my bad, for now I don't even have a 32bit VM to
verify, thus my LSP doesn't warn me about the format.
Thanks,
Qu
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7027 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
2024-01-10 2:03 ` Qu Wenruo
@ 2024-01-10 2:26 ` David Sterba
2024-01-10 2:34 ` Qu Wenruo
0 siblings, 1 reply; 6+ messages in thread
From: David Sterba @ 2024-01-10 2:26 UTC (permalink / raw)
To: Qu Wenruo; +Cc: dsterba, kernel test robot, linux-btrfs, llvm, oe-kbuild-all
On Wed, Jan 10, 2024 at 12:33:17PM +1030, Qu Wenruo wrote:
>
>
> On 2024/1/10 12:29, David Sterba wrote:
> > On Tue, Jan 09, 2024 at 11:02:54AM +0800, kernel test robot wrote:
> >> Hi Qu,
> >>
> >> kernel test robot noticed the following build warnings:
> >>
> >> [auto build test WARNING on kdave/for-next]
> >> [also build test WARNING on next-20240108]
> >> [cannot apply to linus/master v6.7]
> >> [If your patch is applied to the wrong git tree, kindly drop us a note.
> >> And when submitting patch, we suggest to use '--base' as documented in
> >> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >>
> >> url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-zlib-fix-and-simplify-the-inline-extent-decompression/20240108-171206
> >> base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
> >> patch link: https://lore.kernel.org/r/29b7793e53e1cdd559ad212ee69cec211a3b4db2.1704704328.git.wqu%40suse.com
> >> patch subject: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
> >> config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/config)
> >> compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
> >> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/reproduce)
> >>
> >> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> >> the same patch/commit), kindly add following tags
> >> | Reported-by: kernel test robot <lkp@intel.com>
> >> | Closes: https://lore.kernel.org/oe-kbuild-all/202401091012.pLm6PcKG-lkp@intel.com/
> >>
> >> All warnings (new ones prefixed by >>):
> >>
> >>>> fs/btrfs/zlib.c:402:15: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
> >> 401 | pr_warn_ratelimited("BTRFS: infalte failed, decompressed=%lu expected=%lu\n",
> >> | ~~~
> >> | %zu
> >> 402 | to_copy, destlen);
> >> | ^~~~~~~
> >
> > Valid report but I can't reproduce it. Built with clang 17 and
> > explicitly enabled -Wformat. We have additional warnings enabled per
> > directory fs/btrfs/ so we can add -Wformat, I'd like to know what I'm
> > missing, we've had fixups for the size_t printk format so it would make
> > sense to catch it early.
>
> I guess it's due to the platform? (The report is from 32bit system).
Ah I see, I build on 64bit platform but should the Wformat warning also
point out mismatch there? The size_t type is an alias of unsigned long
so it is not an error but when size_t and %zu don't match could be a
platform-independent error, no? This would save us reports and followup
fixups roundtrips.
> Otherwise it's indeed my bad, for now I don't even have a 32bit VM to
> verify, thus my LSP doesn't warn me about the format.
Yeah, it could/should though.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
2024-01-10 2:26 ` David Sterba
@ 2024-01-10 2:34 ` Qu Wenruo
2024-01-10 2:42 ` David Sterba
0 siblings, 1 reply; 6+ messages in thread
From: Qu Wenruo @ 2024-01-10 2:34 UTC (permalink / raw)
To: dsterba; +Cc: kernel test robot, linux-btrfs, llvm, oe-kbuild-all
[-- Attachment #1.1.1: Type: text/plain, Size: 4317 bytes --]
On 2024/1/10 12:56, David Sterba wrote:
> On Wed, Jan 10, 2024 at 12:33:17PM +1030, Qu Wenruo wrote:
>>
>>
>> On 2024/1/10 12:29, David Sterba wrote:
>>> On Tue, Jan 09, 2024 at 11:02:54AM +0800, kernel test robot wrote:
>>>> Hi Qu,
>>>>
>>>> kernel test robot noticed the following build warnings:
>>>>
>>>> [auto build test WARNING on kdave/for-next]
>>>> [also build test WARNING on next-20240108]
>>>> [cannot apply to linus/master v6.7]
>>>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>>>> And when submitting patch, we suggest to use '--base' as documented in
>>>> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>>>>
>>>> url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-zlib-fix-and-simplify-the-inline-extent-decompression/20240108-171206
>>>> base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
>>>> patch link: https://lore.kernel.org/r/29b7793e53e1cdd559ad212ee69cec211a3b4db2.1704704328.git.wqu%40suse.com
>>>> patch subject: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
>>>> config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/config)
>>>> compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
>>>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240109/202401091012.pLm6PcKG-lkp@intel.com/reproduce)
>>>>
>>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>>>> the same patch/commit), kindly add following tags
>>>> | Reported-by: kernel test robot <lkp@intel.com>
>>>> | Closes: https://lore.kernel.org/oe-kbuild-all/202401091012.pLm6PcKG-lkp@intel.com/
>>>>
>>>> All warnings (new ones prefixed by >>):
>>>>
>>>>>> fs/btrfs/zlib.c:402:15: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
>>>> 401 | pr_warn_ratelimited("BTRFS: infalte failed, decompressed=%lu expected=%lu\n",
>>>> | ~~~
>>>> | %zu
>>>> 402 | to_copy, destlen);
>>>> | ^~~~~~~
>>>
>>> Valid report but I can't reproduce it. Built with clang 17 and
>>> explicitly enabled -Wformat. We have additional warnings enabled per
>>> directory fs/btrfs/ so we can add -Wformat, I'd like to know what I'm
>>> missing, we've had fixups for the size_t printk format so it would make
>>> sense to catch it early.
>>
>> I guess it's due to the platform? (The report is from 32bit system).
>
> Ah I see, I build on 64bit platform but should the Wformat warning also
> point out mismatch there? The size_t type is an alias of unsigned long
> so it is not an error but when size_t and %zu don't match could be a
> platform-independent error, no? This would save us reports and followup
> fixups roundtrips.
size_t is defined differently, in include/uapi/asm-generic/posix_types.h:
/*
* Most 32 bit architectures use "unsigned int" size_t,
* and all 64 bit architectures use "unsigned long" size_t.
*/
#ifndef __kernel_size_t
#if __BITS_PER_LONG != 64
typedef unsigned int __kernel_size_t;
typedef int __kernel_ssize_t;
typedef int __kernel_ptrdiff_t;
#else
typedef __kernel_ulong_t __kernel_size_t;
typedef __kernel_long_t __kernel_ssize_t;
typedef __kernel_long_t __kernel_ptrdiff_t;
#endif
#endif
Thus this is the reason why we need @zu for size_t to handle the
difference, and since for 64bit it's just unsigned long, thus compiler
won't give any warning.
(That's also why I tend to not use size_t at all, and why I like rust's
explicit sized type, and we may want to go that path to prefer
u8/u16/u32/u64 when possible)
Thanks,
Qu
>
>> Otherwise it's indeed my bad, for now I don't even have a 32bit VM to
>> verify, thus my LSP doesn't warn me about the format.
>
> Yeah, it could/should though.
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7027 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression
2024-01-10 2:34 ` Qu Wenruo
@ 2024-01-10 2:42 ` David Sterba
0 siblings, 0 replies; 6+ messages in thread
From: David Sterba @ 2024-01-10 2:42 UTC (permalink / raw)
To: Qu Wenruo; +Cc: dsterba, kernel test robot, linux-btrfs, llvm, oe-kbuild-all
On Wed, Jan 10, 2024 at 01:04:06PM +1030, Qu Wenruo wrote:
> >>>>
> >>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> >>>> the same patch/commit), kindly add following tags
> >>>> | Reported-by: kernel test robot <lkp@intel.com>
> >>>> | Closes: https://lore.kernel.org/oe-kbuild-all/202401091012.pLm6PcKG-lkp@intel.com/
> >>>>
> >>>> All warnings (new ones prefixed by >>):
> >>>>
> >>>>>> fs/btrfs/zlib.c:402:15: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
> >>>> 401 | pr_warn_ratelimited("BTRFS: infalte failed, decompressed=%lu expected=%lu\n",
> >>>> | ~~~
> >>>> | %zu
> >>>> 402 | to_copy, destlen);
> >>>> | ^~~~~~~
> >>>
> >>> Valid report but I can't reproduce it. Built with clang 17 and
> >>> explicitly enabled -Wformat. We have additional warnings enabled per
> >>> directory fs/btrfs/ so we can add -Wformat, I'd like to know what I'm
> >>> missing, we've had fixups for the size_t printk format so it would make
> >>> sense to catch it early.
> >>
> >> I guess it's due to the platform? (The report is from 32bit system).
> >
> > Ah I see, I build on 64bit platform but should the Wformat warning also
> > point out mismatch there? The size_t type is an alias of unsigned long
> > so it is not an error but when size_t and %zu don't match could be a
> > platform-independent error, no? This would save us reports and followup
> > fixups roundtrips.
>
> size_t is defined differently, in include/uapi/asm-generic/posix_types.h:
>
> /*
> * Most 32 bit architectures use "unsigned int" size_t,
> * and all 64 bit architectures use "unsigned long" size_t.
> */
> #ifndef __kernel_size_t
> #if __BITS_PER_LONG != 64
> typedef unsigned int __kernel_size_t;
> typedef int __kernel_ssize_t;
> typedef int __kernel_ptrdiff_t;
> #else
> typedef __kernel_ulong_t __kernel_size_t;
> typedef __kernel_long_t __kernel_ssize_t;
> typedef __kernel_long_t __kernel_ptrdiff_t;
> #endif
> #endif
>
> Thus this is the reason why we need @zu for size_t to handle the
> difference, and since for 64bit it's just unsigned long, thus compiler
> won't give any warning.
So it's the int/long difference and kernel does it in a special way due
to absence of the standard libc headers.
> (That's also why I tend to not use size_t at all, and why I like rust's
> explicit sized type, and we may want to go that path to prefer
> u8/u16/u32/u64 when possible)
Yeah, from what I've seen so far is that size_t brings us only problems,
I would not mind conversions to explicit types like u32 or u64. We do
that in many places, I think it's namely on the interface boundaries
where we provide a callback with a size_t type, but from that down it
could be u64.
Quick grep for size_t returns 300+ lines and 100+ of that is ssize_t,
that's still a lot so the conversions should be targeted.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-01-10 2:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <29b7793e53e1cdd559ad212ee69cec211a3b4db2.1704704328.git.wqu@suse.com>
2024-01-09 3:02 ` [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression kernel test robot
2024-01-10 1:59 ` David Sterba
2024-01-10 2:03 ` Qu Wenruo
2024-01-10 2:26 ` David Sterba
2024-01-10 2:34 ` Qu Wenruo
2024-01-10 2:42 ` David Sterba
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox