Hello! I just tried all the new goodness from the latest smatch code. Some good improvements, but seems to introduce some regressions. For one, it used to be all good about "chec something ; lock ; check something again" since it totally makes sense in the kernel, but that seems to be at least somewhat broken. Poster child here in Lustre is ldlm_lvbo_init: http://git.whamcloud.com/fs/lustre-release.git/blob/943612ac470a1f916d44f551eee01c3d51fc9546:/lustre/include/lustre_dlm.h#l1015 static inline int ldlm_lvbo_init(struct ldlm_resource *res) { struct ldlm_namespace *ns = ldlm_res_to_ns(res); int rc = 0; if (ns->ns_lvbo == NULL || ns->ns_lvbo->lvbo_init == NULL || res->lr_lvb_initialized) return 0; mutex_lock(&res->lr_lvb_mutex); /* Did we lose the race? */ if (res->lr_lvb_initialized) { This now produces: lustre/include/lustre_dlm.h:1026 ldlm_lvbo_init() warn: we tested 'res->lr_lvb_initialized' before and it was 'false' Also this snippet: int rct_del(struct rmtacl_ctl_table *rct, pid_t key) { struct rmtacl_ctl_entry *rce; spin_lock(&rct->rct_lock); rce = __rct_search(rct, key); if (rce) rce_free(rce); spin_unlock(&rct->rct_lock); return rce ? 0 : -ENOENT; } http://git.whamcloud.com/fs/lustre-release.git/blob/943612ac470a1f916d44f551eee01c3d51fc9546:/lustre/llite/llite_rmtacl.c#l143 Now produces: lustre/llite/llite_rmtacl.c:153 rct_del() warn: 'rce' was already freed. Now, we are not reaching there so probably could be a bit smarter about that? I guess this might not be a bug, bug a bugfix since apparently we have a similar bit of code in lustre/osc/osc_quota.c (line 127) that produces the same warning since day 1. And finally, while investigating some other case I arrived at this test code below that fails to produce a leak warning: #include "check_debug.h" void kfree(void *); void *kmalloc(int, int); int null_test(void) { char *foo; int bar = 1; foo = kmalloc(GFP_ATOMIC, 1024); __smatch_states("check_leaks"); if (!foo) foo = 1; __smatch_states("check_leaks"); bar = *foo; // kfree(foo); } Presumably when we exit a function with a merged state that contains allocated, but does not contain freed/returned it should 100% warn? hm, after looking at the code, it appears that the only two states are "ok" and "allocated"? Any reason not to track the other two? Bye, Oleg-- 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
