Hi Dan, Hi Julia, Hi Phil, On Wed, May 22, 2019 at 11:16 AM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > On Mon, May 20, 2019 at 10:12:14PM +0530, Himanshu Jha wrote: > > o Why do we have so many open warnings for context imbalance ? Or > > Why did we stop at some point annotating the codebase ? > > > > What we're looking for here is mostly bugs where we forget to drop the > lock on an error path. Sparse isn't a great tool for this because it > doesn't have very sophisticated flow analysis. > > Smatch has decent flow analysis but it too sucks for finding locking > bugs because I wrote the check_locks.c code 10 years ago. I said I > would re-write it seven years ago but I never got around to it. The > smatch check doesn't do cross function analysis, for example... > So, when we would propose a set of annotations to the kernel that would allow a combination of multiple tools (coccinelle, smatch, clang thread safety analysis etc.) to do static analysis of these locking bugs, there is some support here to get this accepted in the code base. Further, I understand now that the locking in sparse has some analysis imprecision, leading to various false positives, and hence, annotating the kernel was eventually stopped due to missing success stories (in addition to the common problem that nobody continued to pick it up at some point in time). So, if we can show that we have static analysis tools clearly superior in its analysis capabilities, coverage and completeness compared to sparse, we could actually drop the current sparse rules, replace or remove the sparse annotations and in the further documentation refer to this new static analysis tools instead, right? That does sound like a good motivation for us to continue our investigation to determine if and possibly finally show that we have a combination of tools that can handle locking bugs statically better than what sparse is currently offering. This then makes a good GSoC project to start this activity and suggests that with further community support this may be continued. Best regards, Lukas
