From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Heming Zhao <heming.zhao@suse.com>
Cc: ocfs2-devel@lists.linux.dev
Subject: Re: [akpm-mm:mm-nonmm-unstable 38/38] fs/ocfs2/resize.c:127:46: sparse: sparse: incorrect type in argument 2 (different base types)
Date: Mon, 25 Mar 2024 19:35:04 +0800 [thread overview]
Message-ID: <e02325da-ae50-412e-8c16-9d6e4056b247@linux.alibaba.com> (raw)
In-Reply-To: <64114b20-c2b5-408e-bf6e-ef7d2e66e573@suse.com>
On 3/25/24 1:28 PM, Heming Zhao wrote:
> Hi Joseph,
>
> On 3/25/24 09:55, Joseph Qi wrote:
>>
>>
>> On 3/23/24 6:51 PM, Heming Zhao wrote:
>>> Hello Joseph,
>>>
>>> Please see my comment, only one warning need to be fixed, others are harmless.
>>> Do I re-send v4 patch or send a new patch?
>>>
>>
>> To make sparse tool happy, we'd better fix all type conversion warnings
>> and then send v4 version.
>>
>> Joseph
>>
>>> On 3/23/24 12:17, kernel test robot wrote:
>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
>>>> head: e393dbc9246c3ae0160a07c8666838056eafbc44
>>>> commit: e393dbc9246c3ae0160a07c8666838056eafbc44 [38/38] ocfs2: improve write IO performance when fragmentation is high
>>>> config: i386-randconfig-061-20240322 (https://download.01.org/0day-ci/archive/20240323/202403231258.mU2k0fih-lkp@intel.com/config)
>>>> compiler: 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/20240323/202403231258.mU2k0fih-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/202403231258.mU2k0fih-lkp@intel.com/
>>>>
>>>> sparse warnings: (new ones prefixed by >>)
>>>>>> fs/ocfs2/resize.c:127:46: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned short [usertype] total_bits @@ got restricted __le16 [usertype] bg_bits @@
>>>> fs/ocfs2/resize.c:127:46: sparse: expected unsigned short [usertype] total_bits
>>>> fs/ocfs2/resize.c:127:46: sparse: got restricted __le16 [usertype] bg_bits
>>>
>>> This warning need to be modified, there should do endian converting.
>>>
>>>>>> fs/ocfs2/resize.c:128:33: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] old_bg_contig_free_bits @@ got restricted __le16 [usertype] bg_contig_free_bits @@
>>>> fs/ocfs2/resize.c:128:33: sparse: expected unsigned short [usertype] old_bg_contig_free_bits
>>>> fs/ocfs2/resize.c:128:33: sparse: got restricted __le16 [usertype] bg_contig_free_bits
>>>
>>> This warning is harmless, the old_bg_contig_free_bits does backup job.
>>> later code logic just uses this value to do restore value job. So we
>>> don't need to do endian converting job.
>
> Are you sure to fix this warning, converting here waste cpu time
> and meaningless.
>
Since it is just used as a saved value, why not define it as __le16?
>>>
>>>>>> fs/ocfs2/resize.c:169:44: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le16 [usertype] bg_contig_free_bits @@ got unsigned short [usertype] old_bg_contig_free_bits @@
>>>> fs/ocfs2/resize.c:169:44: sparse: expected restricted __le16 [usertype] bg_contig_free_bits
>>>> fs/ocfs2/resize.c:169:44: sparse: got unsigned short [usertype] old_bg_contig_free_bits
>>>
>>> see my above comment. just use backup value. no need to convert endian.
>>>
>>>> fs/ocfs2/resize.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
>>>> include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
>>>> include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
>>>
>>> This warning belongs to mm part.
>>>> --
>>>>>> fs/ocfs2/suballoc.c:2566:41: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] old_bg_contig_free_bits @@ got restricted __le16 [usertype] bg_contig_free_bits @@
>>>> fs/ocfs2/suballoc.c:2566:41: sparse: expected unsigned short [usertype] old_bg_contig_free_bits
>>>> fs/ocfs2/suballoc.c:2566:41: sparse: got restricted __le16 [usertype] bg_contig_free_bits
>>>
>>> Like above, there code do backup job, no need to convert endian.
>>>> fs/ocfs2/suballoc.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
>>>> include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
>>>> include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
>>> There belongs to mm.
>>>
>>>> fs/ocfs2/suballoc.c:2493:17: sparse: sparse: context imbalance in 'ocfs2_block_group_clear_bits' - different lock contexts for basic block
>>>
>>> from [1], this warning is harmless.
>>>
>>> [1]: https://lwn.net/Articles/109066/
>>>
>
> I tried some methods to fix 'context imbalance' warning but failed.
> Do you have idea to resolve it?
>
Seems sparse is not suitable for checking the following code style:
if (condition)
spin_lock(&lock);
...
if (condition)
spin_unlock(&lock);
I don't have a better idea to eliminate this warning. Seems we have to
leave it alone.
Thanks,
Joseph
prev parent reply other threads:[~2024-03-25 11:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202403231258.mU2k0fih-lkp@intel.com>
2024-03-23 10:51 ` [akpm-mm:mm-nonmm-unstable 38/38] fs/ocfs2/resize.c:127:46: sparse: sparse: incorrect type in argument 2 (different base types) Heming Zhao
2024-03-25 1:55 ` Joseph Qi
2024-03-25 5:28 ` Heming Zhao
2024-03-25 11:35 ` Joseph Qi [this message]
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=e02325da-ae50-412e-8c16-9d6e4056b247@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=heming.zhao@suse.com \
--cc=ocfs2-devel@lists.linux.dev \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).