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 "$".
> 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.
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
