[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AD300C8.3090502@gmail.com>
Date: Mon, 12 Oct 2009 12:11:20 +0200
From: Jiri Slaby <jirislaby@...il.com>
To: Ingo Molnar <mingo@...e.hu>
CC: Johannes Berg <johannes@...solutions.net>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Stanse 1.0.0 released [was: wireless: wl12xx, fix lock imbalance]
On 07/18/2009 06:10 PM, Ingo Molnar wrote:
>>> 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?
Hi all. I'm pleased to announce the first official Stanse release.
For those who are interested, the tool (with other information and
documentation) is available at
http://stanse.fi.muni.cz/
There are also prebuilt rpm packages for openSUSE and Fedora 11. (Some
of them still building, will be available soon. Sorry for that, build
service is slow as hell these days.)
Also I pre-ran the stanse on 2.6.32-rc3 with results available online.
The webpage concerning this is at:
http://decibel.fi.muni.cz/~xslaby/stanse/?db=32-rc
So for those who are not interested in the toolkit itself but only in
results from more-or-less latest kernel may try it that way.
There are many janitor-like bugs. E.g. not testing return values from
k*alloc might be seamlessly taken care of by janitors, I think.
As it's only static analysis not based on symbolic execution (we will
play with that later), there are some/many (depending on a checker) many
false positives. There is a mechanism for marking them. I ask everybody
who finds a FP or error to mark the entry as such.
I'm still trying to lower FP rate. If somebody finds out another method
to do so, please share with us.
Any input appreciated. Hope it helps.
Thanks to those who support us,
--js
--
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/
Powered by blists - more mailing lists