LKML Archive on
help / color / mirror / Atom feed
From: Harvey Harrison <>
To: Heiko Carstens <>
Cc: Andrew Morton <>,
	LKML <>,
	Masami Hiramatsu <>,
	Ananth N Mavinakayanahalli <>,
	David Miller <>,,,, Ingo Molnar <>,
	Paul Mackerras <>
Subject: Re: [PATCHv3] kprobes: Introduce kprobe_handle_fault()
Date: Tue, 08 Jan 2008 22:22:22 -0800	[thread overview]
Message-ID: <1199859742.6424.44.camel@brick> (raw)
In-Reply-To: <>

On Wed, 2008-01-09 at 07:14 +0100, Heiko Carstens wrote:
> > +/*
> > + * If it is a kprobe pagefault we can not be premptible so return before
> Missing 'e' in preemptible.


> However, the old code you removed had a lot of preempt_disable/enable calls
> that you removed. Hope you checked that preemption was always disabled
> already and the calls were not necessary (true at least for s390).
> Are there cases where this code could be called with preemption enabled?
> If so then that looks like a bug anyway. I'd say the preemptible check
> should be removed or turned into a WARN_ON.
> I like this better (not including any other changes):
> 	if (!user_mode(regs) && !preemptible() && kprobe_running())
> 		return kprobe_fault_handler(regs, trapnr);
> 	return 0;

I could live with that too, will defer to kprobes maintainers if they
prefer that as a follow-on.

Regarding the preempt_enable/disable, the reasoning behind it comes from
the following, I stole the changelog from x86.git which has a good
description of why this should be safe:

commit 6624c638928acce52fbe57d73284efcf9f86abd2
Author: Quentin Barnes <>
Date:   Wed Jan 9 02:32:57 2008 +0100

    Code clarification patch to Kprobes arch code
    When developing the Kprobes arch code for ARM, I ran across some
    found in x86 and s390 Kprobes arch code which I didn't consider as
    good as it could be.
    Once I figured out what the code was doing, I changed the code
    for ARM Kprobes to work the way I felt was more appropriate.
    I've tested the code this way in ARM for about a year and would
    like to push the same change to the other affected architectures.
    The code in question is in kprobe_exceptions_notify() which
              /* kprobe_running() needs smp_processor_id() */
              if (kprobe_running() &&
                  kprobe_fault_handler(args->regs, args->trapnr))
                      ret = NOTIFY_STOP;
    For the moment, ignore the code having the preempt_disable()/
    preempt_enable() pair in it.
    The problem is that kprobe_running() needs to call
    which will assert if preemption is enabled.  That sanity check by
    smp_processor_id() makes perfect sense since calling it with
    enabled would return an unreliable result.
    But the function kprobe_exceptions_notify() can be called from a
    context where preemption could be enabled.  If that happens, the
    assertion in smp_processor_id() happens and we're dead.  So what
    the original author did (speculation on my part!) is put in the
    preempt_disable()/preempt_enable() pair to simply defeat the check.
    Once I figured out what was going on, I considered this an
    inappropriate approach.  If kprobe_exceptions_notify() is called
    from a preemptible context, we can't be in a kprobe processing
    context at that time anyways since kprobes requires preemption to
    already be disabled, so just check for preemption enabled, and if
    so, blow out before ever calling kprobe_running().  I wrote the ARM
    kprobe code like this:
              /* To be potentially processing a kprobe fault and to
               * trust the result from kprobe_running(), we have
               * be non-preemptible. */
              if (!preemptible() && kprobe_running() &&
                  kprobe_fault_handler(args->regs, args->trapnr))
                      ret = NOTIFY_STOP;
    The above code has been working fine for ARM Kprobes for a year.
    So I changed the x86 code (2.6.24-rc6) to be the same way and ran
    the Systemtap tests on that kernel.  As on ARM, Systemtap on x86
    comes up with the same test results either way, so it's a neutral
    external functional change (as expected).
    This issue has been discussed previously on linux-arm-kernel and the
    Systemtap mailing lists.  Pointers to the by base for the two



  reply	other threads:[~2008-01-09  6:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-07 20:24 [PATCHv2] kprobes: Introduce is_kprobe_fault() Harvey Harrison
2008-01-08  5:37 ` Ananth N Mavinakayanahalli
2008-01-08 17:03 ` Masami Hiramatsu
2008-01-08 22:45 ` Paul Mackerras
2008-01-08 23:02   ` Harvey Harrison
2008-01-09  4:19     ` [PATCHv3] kprobes: Introduce kprobe_handle_fault() Harvey Harrison
2008-01-09  6:14       ` Heiko Carstens
2008-01-09  6:22         ` Harvey Harrison [this message]
2008-01-09 22:01           ` [PATCHv4] " Harvey Harrison
2008-01-09 23:16             ` Heiko Carstens
2008-01-10  0:25               ` Harvey Harrison
2008-01-10  0:44               ` [PATCH 1/2] " Harvey Harrison
2008-01-10  3:15                 ` Masami Hiramatsu
2008-01-10 12:50                 ` Ingo Molnar
2008-01-10  0:45               ` [PATCH 2/2] kprobe: remove preempt_enable/disable from kprobe_handle_fault() Harvey Harrison
2008-01-10  3:15                 ` Masami Hiramatsu
2008-01-09 23:31             ` [PATCHv4] kprobes: Introduce kprobe_handle_fault() Masami Hiramatsu
2008-01-09  7:58         ` [PATCHv3] " Christoph Hellwig
2008-01-09  7:57       ` Christoph Hellwig

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:

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

  git send-email \
    --in-reply-to=1199859742.6424.44.camel@brick \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCHv3] kprobes: Introduce kprobe_handle_fault()' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).