linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Christopher Li" <sparse@chrisli.org>
To: Codrin Alexandru Grajdeanu <grcodal@gmail.com>
Cc: linux-sparse@vger.kernel.org, Octavian Purdila <tavi@cs.pub.ro>
Subject: Re: Interrupt context
Date: Mon, 24 Mar 2008 14:00:32 -0700	[thread overview]
Message-ID: <70318cbf0803241400m46d30098g85a402e6e0f86130@mail.gmail.com> (raw)
In-Reply-To: <3581ed890803231444i58cff10i408dc4d9bef7b184@mail.gmail.com>

On Sun, Mar 23, 2008 at 2:44 PM, Codrin Alexandru Grajdeanu
<grcodal@gmail.com> wrote:
>   To test this, sparse would be required to run twice. First to get all
>   interrupt context functions, by verifying what arguments are passed to
>   irq_handler_t() and what values are passed to the function pointers in

You can identify the interrupt handler by return type is "irqreturn_t".

>   struct timer_list, softirq_action and tasklet_struct. The second run

That is harder.

>   would generate the call graph for this function and would verify if
>   schedule() is called inside their call graph.

I don't think two pass is enough. You need to build the call graph
for pretty much every function. Because the irq handler function might
call other function which calls other function which calls schedule().

I don't think you can go very far without doing any control flow
and data flow analyze. e.g. kmalloc() can go to sleep or not depend
on the allocation flag (GFP_ATOMIC).

Which points back to the proposal of:
a) allow sparse to access  function from different files.
b) building the call graph for every function in the kernel.

Chris

  reply	other threads:[~2008-03-24 21:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-23 21:44 Interrupt context Codrin Alexandru Grajdeanu
2008-03-24 21:00 ` Christopher Li [this message]
2008-03-25  1:34   ` Octavian Purdila
2008-03-25  2:57     ` Christopher Li
2008-03-26 12:43       ` Octavian Purdila
2008-03-26 21:53         ` Christopher Li

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=70318cbf0803241400m46d30098g85a402e6e0f86130@mail.gmail.com \
    --to=sparse@chrisli.org \
    --cc=grcodal@gmail.com \
    --cc=linux-sparse@vger.kernel.org \
    --cc=tavi@cs.pub.ro \
    /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;
as well as URLs for NNTP newsgroup(s).