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. regards, dan carpenter
Attachment:
signature.asc
Description: Digital signature