On Tue, Apr 04, 2023 at 03:20:44PM +0800, Dongliang Mu wrote:
> Hi Dan,
>
> As you mentioned before, check_unwind.c leverages paired functions to
> catch unmatch states, e.g., request_irq/free_irq, ioremap/iounmap.
> Since I am not very familiar with Smatch, I have some questions about
> this single check:
> 1. Does this check search all the paths in one function and match the
> paired functions?
Basically what it does is if you have an alloc:
foo = my_alloc(); // <-- sets state of "foo" to my_alloc();
Then there are a couple ways functions can be released:
free(foo); // <-- simple. set "foo" to &release
free_everything(p); // <-- slightly complicated. sets "foo" to
// &release or &unknown (&unknown is actually
// more powerful than &release)
Then after the end of the function it looks at all the returns in
match_check_balanced(). It goes through each state and says "If this
variable is not free and it is an error path then warn".
There are couple ways that this can go wrong. If the allocation
function returns are not split apart properly between success and
failure then Smatch will ignore the allocation. No warning.
The main way that freeing goes wrong is when it's hard to track
free_everything() back to a specific variable. For example, we call
free_everthing(p) but the variable which is freed is in the
container_of(p). I could probably make a list of struct members which
are freed but we can't figure out how to tie them to a parameter.
Smatch does this for check_locking.c
Also it's sometimes hard to split the success paths and the failure
paths.
regards,
dan carpenter
