All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Oleg Nesterov <oleg@redhat.com>
Cc: linux-kernel@vger.kernel.org, ananth@in.ibm.com,
	a.p.zijlstra@chello.nl, mingo@redhat.com,
	srikar@linux.vnet.ibm.com, roland@hack.frob.com
Subject: Re: [PATCH 2/2] x86/uprobes: implement x86 specific arch_uprobe_*_step
Date: Tue, 31 Jul 2012 21:30:59 +0200	[thread overview]
Message-ID: <50183273.9070304@linutronix.de> (raw)
In-Reply-To: <20120731175108.GC14576@redhat.com>

On 07/31/2012 07:51 PM, Oleg Nesterov wrote:
> However, honestly I do not like it. I think we should change this
> step-by-step, that is why I suggested to use TIF_SINGLESTEP and
> user_enable_single_step() like your initial patch did. With this
> patch at least the debugger doesn't lose the control over the tracee
> if it steps over the probed insn, and this is the main (and known ;)
> problem to me.

I thought you did not like the nesting with TIF_SIGNLESTEP and the
_FORCE and suggested to handle the complete state within uprobe.

> Every change needs the discussion. For example, _enable should
> clear DEBUGCTLMSR_BTF, this is obvious. But it is not clear to
> me if _disable should restore it. What if the probed insn was
> "jmp"? We need the additional complications to handle this case
> really correctly, and for what? OK, gdb can get the extra SIGTRAP
> from the tracee, but this is fine. And uprobes can confuse gdb
> in many ways.

I don't know if it is worth to have correct behavior here or rather go
for the easy way which is either always do the wakeup or delay until
the next jump.

Sebastian

  reply	other threads:[~2012-07-31 19:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-26 15:20 [PATCH] uprobes: don't enable/disable signle step if the user did it Sebastian Andrzej Siewior
2012-07-26 17:31 ` Oleg Nesterov
2012-07-27 17:39   ` Sebastian Andrzej Siewior
2012-07-27 18:04     ` Oleg Nesterov
2012-07-26 17:38 ` Sebastian Andrzej Siewior
2012-07-30 11:06 ` Ananth N Mavinakayanahalli
2012-07-30 14:16   ` Oleg Nesterov
2012-07-30 15:15     ` Sebastian Andrzej Siewior
2012-07-31  4:01     ` Ananth N Mavinakayanahalli
2012-07-31  5:22     ` Srikar Dronamraju
2012-07-31 17:38       ` Oleg Nesterov
2012-07-31 11:52     ` [PATCH 1/2] uprobes: Use a helper instead of ptrace's single step enable Sebastian Andrzej Siewior
2012-07-31 11:52       ` [PATCH 2/2] x86/uprobes: implement x86 specific arch_uprobe_*_step Sebastian Andrzej Siewior
2012-07-31 17:51         ` Oleg Nesterov
2012-07-31 19:30           ` Sebastian Andrzej Siewior [this message]
2012-08-01 12:26             ` Oleg Nesterov
2012-08-01 13:01               ` Q: user_enable_single_step() && update_debugctlmsr() Oleg Nesterov
2012-08-01 13:32                 ` Sebastian Andrzej Siewior
2012-08-01 13:46                   ` Oleg Nesterov
2012-08-01 13:54                     ` Sebastian Andrzej Siewior
2012-08-01 14:01                       ` Oleg Nesterov
2012-08-01 14:21                         ` Sebastian Andrzej Siewior
2012-08-01 14:31                           ` Oleg Nesterov
2012-08-01 14:47                             ` Oleg Nesterov
2012-08-01 14:51                             ` Sebastian Andrzej Siewior
2012-08-01 15:01                               ` Oleg Nesterov
2012-08-01 15:12                                 ` Sebastian Andrzej Siewior
2012-08-01 15:14                                   ` Oleg Nesterov
2012-08-01 18:46                                     ` Sebastian Andrzej Siewior
2012-08-02 13:05                                       ` Oleg Nesterov
2012-08-02 13:20                                         ` Sebastian Andrzej Siewior
2012-08-02 13:24                                           ` Oleg Nesterov
2012-08-01 13:43         ` [PATCH 2/2] x86/uprobes: implement x86 specific arch_uprobe_*_step Oleg Nesterov
2012-08-02  4:58           ` Ananth N Mavinakayanahalli
2012-07-31 17:40       ` [PATCH 1/2] uprobes: Use a helper instead of ptrace's single step enable Oleg Nesterov

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=50183273.9070304@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ananth@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=roland@hack.frob.com \
    --cc=srikar@linux.vnet.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.