Re: [PATCH] wireless: wl12xx, fix lock imbalance

[Ingo Molnar <mingo@elte.hu>]

* Johannes Berg <johannes@sipsolutions.net> wrote:

> > It would work like this: __acquires()/__releases() would also 
> > emit section markers like __lockfunc, and lockdep would warn 
> > about functions that return with unbalanced locks, irqs or 
> > preempt counts and do not declare themselves as locking related 
> > functions.
> > 
> > This would help catch imbalances at their source.
> 
> I don't see a need to do it dynamically since sparse warns about 
> things like this. It's quirky in some ways and I've tried to fix 
> it up before (and failed) but it's not something that can't be 
> fixed, it just needs more than a night of hacking.

Yeah - but Sparse warns about this if it can analyze the code path. 
If it cannot see through it then it cannot warn. Static analysis 
will go only that far - dynamic analysis will catch the cases that 
do happen.

So it's best to have both: static analysis is good at finding 
imbalances even if they have a very low likelyhood of occuring in 
practice, while dynamic analysis will catch everything that does 
trigger in practice, regardless of code flow complexity.

( The only white area on the map is rarely executed code that has a
  complex code flow. Such code is being frowned upon in general at 
  the review stage. )

> > Plus static tools like Jiri is working on are very useful as 
> > well. I think Coverty does that too and it's a pity we dont have 
> > free tools for that. In fact Covery will sweep clean the kernel 
> > of such bugs, giving OSS tools like 'stanse' the false 
> > impression that there are no such bugs. There are such bugs - 
> > there's a constant influx of them. So please work on this, it 
> > looks very useful.
> 
> What's "this" in this context?

this == stanse, the static code analyzing thing Jiri mentioned he is 
working on. The webpage says it will be under the GPL - that's good. 
Jiri, any release date for the source code?

	Ingo