Re: [KJ] Re: [PATCH] bugfix GFP_KERNEL -> GFP_ATOMIC in spin_locked region

[Randy Dunlap <randy.dunlap@oracle.com>]

On Tue, 05 Jun 2007 18:31:42 +0200 Yoann Padioleau wrote:

> Oliver Neukum <oneukum@suse.de> writes:
> 
> > Am Dienstag, 5. Juni 2007 13:05 schrieb Yoann Padioleau:
> >> Ok. Do you have a preference on the format ?  a <file>:<line> format  ?
> >> 
> >> Is there a place that gathered all those implicit programming rules 
> >> (that copy_from_user must not be called inside a spinlock, etc) so that
> >> I can translate them in a script for our tool.
> >
> > How much C does your tool understand? 
> 
> The tool understands almost all the C language but the analysis we do
> for the moment are intra-procedural so when we look for 
>  spin_lock();
>  ...
>  copy_from_user();
> 
> it can detect cases and code paths only when the two function calls
> are in the same function. It could be extended but it would require to
> do a full analysis of the kernel source. Maybe if some functions of
> the library have an attribute in their prototype in the .h such as
> 
>  __might_sleep copy_from_user(); 
> 
> it could help.
> 
> > You might basically
> > test for code paths that go to "might_sleep()"
> 
> Ok, thanks. If you know other implicit programming rules,
> I would be glad to know them, or if you know places
> where thus rules are written.
> 
> 
> BTW at one point I think the Linux community were using advanced
> static analysis tools such as the one made by Dawson Engler (now
> Coverity). The communitty have stopped using such tools ? Isn't the
> role of sparse to detect bugs such as the dangerous copy_from_user()
> inside spinlocked region ?
> 

There are a few people who have registered for access to the
Coverity database and occasionally go thru it looking for bugs
and then posting fixes.

sparse can check for unbalanced locking, but it needs annotations
for those AFAIK.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/