Re: [PATCH 1/3] btrfs: zlib: fix and simplify the inline extent decompression

public inbox for llvm@lists.linux.dev
 help / color / mirror / Atom feed

* 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