Thanks. That helped. I've fixed it, but it will take me a while to push because I'm in the middle of some stuff... From: Dan Carpenter <dan.carpenter@xxxxxxxxxx> Subject: [PATCH] leaks: don't reset states to themselves Take this sample code: foo = kmalloc(); <- set state to &allocated here if (!foo) return -ENOMEM; <- state should be &ok here if (!bar) return -EINVAL; <- state should be &allocated here So when we get to the condition "if (!foo) ", the most likely scenario is that we start with state &allocated. In the original code, we set the true side to &allocated (which it already was) and the false side to &ok (meaning that it's ok to return here because it won't leak). The problem is that setting it from &allocated to &allocated meant that we screwed up the implications so when the implication code said "Have we changed the state since our implication the answer was yes when really it should have been no." Then, because implications weren't working correctly, it lead to false positives. Reported-by: Amir Vadai <amir@xxxxxxxx> Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx> --- check_leaks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/check_leaks.c b/check_leaks.c index 25a0ae0..b995f7b 100644 --- a/check_leaks.c +++ b/check_leaks.c @@ -142,7 +142,7 @@ static void match_condition(struct expression *expr) case EXPR_DEREF: sm = get_sm_state_expr(my_id, expr); if (sm && slist_has_state(sm->possible, &allocated)) - set_true_false_states_expr(my_id, expr, &allocated, &ok); + set_true_false_states_expr(my_id, expr, NULL, &ok); return; case EXPR_ASSIGNMENT: /* You have to deal with stuff like if (a = b = c) */ -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe smatch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
