public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@redhat.com>
To: Marlow Weston <miwesto@sandia.gov>
Cc: ananth@in.ibm.com, davem@davemloft.net, mhiramata@redhat.com,
	linux-kernel@vger.kernel.org, anil.s.keshavamurthy@intel.com
Subject: Re: HELP!  KProbes bug
Date: Thu, 28 Aug 2008 13:03:11 -0400	[thread overview]
Message-ID: <48B6DA4F.6090601@redhat.com> (raw)
In-Reply-To: <48B6D03C.9090906@sandia.gov>

Hi Marlow,

Marlow Weston wrote:
> Hello persons in the current kernel maintainers file under KProbes:
> 
> I can't find this bug reported anywhere nor somewhere useful for 
> reporting it, so I chose that location to find people to write.  If 
> there is somewhere else I should be sending this to, please tell me and 
> I will redirect it there.
> 
> I think I have found a KProbes bug when I turn on the KProbes via a proc 
> file call instead of via the init code.  The stack trace is attached and 
> seems to indicate a locking issue.  Also attached is module code that 
> will make this happen.  Any advice on where to start hunting this down 
> would be greatly appreciated.
> 
> If the KProbes are going by quickly, ie there is no 
> schedule_timeout_interrupt(), then the problem doesn't show up.  This 
> problem is exacerbated by the probes actually doing things that take 
> time while other probes are attempting to register.  Also, I don't 
> believe it has to do with any particular probe as which probe locks up 
> varies (and my mad attempts at commenting out various probes did not work).

Why would you like to call scheduler from probe handler?

By design, kprobe handler MUST NOT call scheduling functions because it
checks recursive call by using per-cpu variable and scheduler might move
probed process to other cpu. Especially, since kretprobe uses a spinlock
(or hashed spinlocks on recently kernel), if the handler calls scheduler,
it will cause deadlock.

Anyway, if you read Documentation/kprobes.txt carefully, you can find
below paragraph;

---
5. Kprobes Features and Limitations
[...]
Probe handlers are run with preemption disabled.  Depending on the
architecture, handlers may also run with interrupts disabled.  In any
case, your handler should not yield the CPU (e.g., by attempting to
acquire a semaphore).
---
(I think this note should prohibit process scheduling more clearly.)

So, it's not a bug of kprobes. It's a known limitation.

Thank you,


-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com


      reply	other threads:[~2008-08-28 17:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-28 16:20 HELP! KProbes bug Marlow Weston
2008-08-28 17:03 ` Masami Hiramatsu [this message]

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=48B6DA4F.6090601@redhat.com \
    --to=mhiramat@redhat.com \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramata@redhat.com \
    --cc=miwesto@sandia.gov \
    /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