Re: Need help with understanding format in check_unwind.c

On 30/10/23 4:26 pm, Dan Carpenter wrote:
> 
> You're exactly right for points 1 and 2.
> 
> On Mon, Oct 30, 2023 at 03:54:17PM +0530, Harshit Mogalapalli wrote:
>> 3. Fourth parameter:
>>
>> Variable name: "$" it can be anything
>>
>> Sometimes: like in:
>>
>> { "request_free_mem_region", ALLOC,   -1, "$->start", &valid_ptr_min_sval,
>> &valid_ptr_max_sval}
>>
>> Why did we use $->start ?
>>
>> That is because the caller(dmirror_allocate_chunk()) passes start which is a
>> struct member?
>>
>> Can you explain a bit more on this ?
>>
> 
> To be honest, that's probably just a mistake.  I don't know why I
> tracked "$->start" instead of just "$".
> 
Oh okay,
1926 struct resource *request_free_mem_region(struct resource *base,
1927                 unsigned long size, const char *name)
1928 {

So this should be:

{ "request_free_mem_region", ALLOC, -1 , "$", &valid_ptr_min_sval, 
&valid_ptr_max_sval}

Can you explain a bit more on why are we interested in the return value 
instead of just saying we are interested in resource here on this :
and have third param as -1 instead of just 0(resource) ?



> 
>> 4. For ALLOC 4th and 5th params are the range of values in the success path
>> ?
>>
>> Can you please explain filling up these values for one or two APIs ?
> 
> So the issue there is that we're find missing frees.  If the allocation
> doesn't succeed then there is no need to free.
> 
> Some functions always succeed:
> 	{ "set_reloc_control", ALLOC,   0, "$"},
> 	{ "unset_reloc_control", RELEASE, 0, "$"},
> 
> Some return 0 on success.
> 
> 	{ "__class_register", ALLOC, 0, "$", &int_zero, &int_zero },
> 
> Some return a valid pointer.
> 
> 	{ "alloc_workqueue", ALLOC, -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval },
> 
> Smatch tries to split returns into useful information.  This is the
> success path, this is the failure path etc.
> 
Thanks a lot for explaining this.

Regards,
Harshit

> In this check_unwind.c script when there is an allocation which might
> fall outside the range then we don't set the state to allocated.  So if
> the function returns unknown then it's not an allocation.  But say we
> listed the success range as &int_zero to &int_ten (just an example) and
> the return was 7 then that would fall entirely in the success range and
> it's treated as a success.  return_implies_param_key_exact() vs
> return_implies_param_key().
> 
> regards,
> dan carpenter