public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yoann Padioleau <padator@wanadoo.fr>
To: Oliver Neukum <oneukum@suse.de>
Cc: Yoann Padioleau <padator@wanadoo.fr>,
	kernel-janitors@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [KJ] Re: [PATCH] bugfix GFP_KERNEL -> GFP_ATOMIC in spin_locked region
Date: Tue, 05 Jun 2007 18:31:42 +0200	[thread overview]
Message-ID: <87ejkqe51t.fsf@wanadoo.fr> (raw)
In-Reply-To: <200706051333.12219.oneukum@suse.de> (Oliver Neukum's message of "Tue, 5 Jun 2007 13:33:11 +0200")

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 ?


>
> 	Regards
> 		Oliver
>
> _______________________________________________
> Kernel-janitors mailing list
> Kernel-janitors@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors


  reply	other threads:[~2007-06-05 16:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-04 16:25 [PATCH] bugfix GFP_KERNEL -> GFP_ATOMIC in spin_locked region Yoann Padioleau
2007-06-05  4:00 ` Andrew Morton
2007-06-05  4:08   ` Andrew Morton
2007-06-05  8:51     ` Oliver Neukum
2007-06-05 11:05   ` [KJ] " Yoann Padioleau
2007-06-05 11:33     ` Oliver Neukum
2007-06-05 16:31       ` Yoann Padioleau [this message]
2007-06-05 16:48         ` Randy Dunlap
2007-06-05 16:12     ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ejkqe51t.fsf@wanadoo.fr \
    --to=padator@wanadoo.fr \
    --cc=kernel-janitors@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oneukum@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox