[External] Re: [PATCH 1/5] maple_tree: Move the check forward to avoid static check warning.

Peng Zhang zhangpeng.00 at bytedance.com
Thu Nov 16 01:18:21 PST 2023


Hello Liam,

在 2023/11/13 23:09, Dan Carpenter 写道:
> On Mon, Nov 13, 2023 at 10:44:02AM +0800, Peng Zhang wrote:
>>
>>
>> 在 2023/11/10 22:49, Liam R. Howlett 写道:
>>> * Peng Zhang <zhangpeng.00 at bytedance.com> [231109 07:43]:
>>>> Put the check for gap before its reference to avoid Smatch static check
>>>> warnings. This is not a bug, it's just a validation program.
>>>>
>>>> Reported-by: Dan Carpenter <dan.carpenter at linaro.org>
>>>> Closes: http://lists.infradead.org/pipermail/maple-tree/2023-November/003046.html
>>>> Signed-off-by: Peng Zhang <zhangpeng.00 at bytedance.com>
>>>> ---
>>>>    lib/maple_tree.c | 6 +++++-
>>>>    1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
>>>> index aaba453b0d30..1dfbcb74787a 100644
>>>> --- a/lib/maple_tree.c
>>>> +++ b/lib/maple_tree.c
>>>> @@ -7249,6 +7249,11 @@ static void mas_validate_gaps(struct ma_state *mas)
>>>>    counted:
>>>>    	if (mt == maple_arange_64) {
>>>> +		if (!gaps) {
>>>> +			MT_BUG_ON(mas->tree, 1);
>>>> +			return;
>>>
>>> Since MT_BUG_ON() will BUG_ON(), is there a reason to return?
>>>
>>> The only reason I've used braces to BUG_ON() is to include extra error
>>> text, but you haven't provided any here.  I think you could do this (or
>>> MT_BUG_ON() variant, if you prefer):
>>>
>>> MAS_BUG_ON(mas, gaps == NULL);
>> Because MT_BUG_ON() in the maple tree may not invoke BUG_ON() and continue
>> execution, this code is written to prevent the static checker from issuing
>> further warnings. (Dan Carpenter informed me of this a long time ago.)
> 
> Yeah.  Smatch will see this as a test for NULL followed by an untest
> dereference.  We could do the return as you suggest, or we could
> 
> 1) ignore the smatch warning
> 
> or
> 
> 2) make smatch ignore MT_BUG_ON() like it does with other ASSERT()
>     statements.  (This is fine because we're hopefully not putting
>     side effects into the MAS_BUG_ON() call like:
> 
> 	MAS_BUG_ON(mas, p = kmalloc());
Liam, What do you think is the best way to handle this?
I'm planning to submit the next version to LKML.

Thanks,
Peng
> 
> regards,
> dan carpenter
> 



More information about the maple-tree mailing list