linux-kernel - Re: [PATCH] wireless: wl12xx, fix lock imbalance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 18 Jul 2009 18:10:29 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jiri Slaby <jirislaby@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] wireless: wl12xx, fix lock imbalance

* Johannes Berg <johannes@...solutions.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/