Re: Quick question on extending/using smatch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Mon, Mar 05, 2012 at 10:01:24AM +0100, Lars Segerlund wrote:
>  Hi,
>  I have been looking a bit on using smatch to check for non preemtable
> parts of the linux kernel, and parts which have locks held for a long
> time.
>  Specificly to improve realtime behaviour for device drivers ...
>  If I understand it right when doing an analysis with smatch, you get
> the whole parse tree in memory, so I figured that it would be dooable
> to check for locking and disabling preemption in the kernel in the in
> memory tree ?
>  Does this sound about right ? ie. have I understood smatch
> corrrectly, and do you think it would be a reasonable task ?

I don't think so.  The cross function stuff is really weak.

It just does flow analysis.

There is a smatch script for locking bugs, in check_locking.c but
it's really pretty crap.  It looks for calls to spin_lock() and
spin_unlock() and complains about double locks etc.  The other
problem with the check is that Smatch works on the preprocessed code
and many of the calls to locking are macros.

The other problem is that smatch doesn't look at the memory.  For
example, it doesn't recognize how "foo" and "foo->bar" are related.
It just sees them as independent variables.  Eventually hopefully
this will change.

dan carpenter

Attachment: signature.asc
Description: Digital signature

[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Video Projectors]     [PDAs]     [Free Online Dating]     [Hacking TiVo]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]     [Big List of Linux Books]

Add to Google Powered by Linux