function_hooks: don't be too ambitious faking parameter assignments
commitee12c54ac0b358f8817edbbea560cb80d30ca320
authorDan Carpenter <dan.carpenter@oracle.com>
Wed, 14 Mar 2018 13:20:08 +0000 (14 16:20 +0300)
committerDan Carpenter <dan.carpenter@oracle.com>
Wed, 14 Mar 2018 13:21:03 +0000 (14 16:21 +0300)
treed0bbec26d57d23a9f372c8a56955ba2246ec1e17
parent4df485caecfb5dd984e2e29084ef959297aef45f
function_hooks: don't be too ambitious faking parameter assignments

The story here is you have code like kfifo_out_locked() where it takes
the whole macro and passes it through the __kfifo_uint_must_check_helper()
function just to get the __must_check annotation.  So it returns $0.

We should parse this correctly, really, but we don't.

First of all in that case e should be faking that "len = __ret;" but we
instead fake the *whole* huge expression statement.  I just thought of that
now, writing this changelog.

But also there is something wrong with how we parse it and it ends up
causing locking false positives because we end up parsing the lock and
unlock twice.  I don't know exactly why this is...  I am a bad person for
not investigating fully.  Perhaps it has to do with nesting levels and when
we give up.

And, finally, there is another issue with parsing code twice which has
side effects so we really shouldn't be doing it.  I looked at changing
how fake assignments are handled in smatch_flow but it turned out to be a
bit subtle so I gave up.

The bottom line is, it easiest to only try faking it for straight forward
arguments and not very involved ones like expression statements.

Also we should only be faking vanilla assignments, not += and -= etc.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch_function_hooks.c