From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@redhat.com>,
Roland McGrath <roland@hack.frob.com>
Subject: Re: [PATCH] uprobes: don't enable/disable signle step if the user did it
Date: Tue, 31 Jul 2012 10:52:27 +0530 [thread overview]
Message-ID: <20120731052226.GA5087@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120730141638.GA5306@redhat.com>
* Oleg Nesterov <oleg@redhat.com> [2012-07-30 16:16:38]:
> On 07/30, Ananth N Mavinakayanahalli wrote:
> >
> > On Thu, Jul 26, 2012 at 05:20:43PM +0200, Sebastian Andrzej Siewior wrote:
> > > If someone is using single stepping over uprobe brackpoint then after
> > > we pass the uprobe single step, single stepping is disabled and the user
> > > who enebaled them in the first place does not know anything about this.
> > >
> > > This patch avoids enabling / disabling the single step mode if it is
> > > already enabled.
> >
> > This could happen any time 2 different entities call the
> > user_(en/dis)able_single_step() helpers on the same thread.
>
> Yes. But nobody except ptrace should do use these helpers, I think.
>
> > Wouldn't the right way to fix it be to teach these helpers
> > to honor what the TIF_SINGLESTEP
>
> Well, I think uprobes should not use TIF_SINGLESTEP at all. This
> bit is (mostly) needed to handle the stepping over syscall. But
> I guess you didn't actually mean TIF_SINGLESTEP...
>
> > flag setting was in the first place?
>
> Perhaps, but I don't think so. If nothing else, we do not want
> to add the new counter/whatever in task_struct, while uprobes
> already has uprobe_task which can "remember" the state of _TF
> bit and more.
>
> And this can't solve other problems. Suppose that gdb does
> PTRACE_SINGLESTEP but the original "popf" insn was already replaced
> by "int3", this will obviously confuse is_setting_trap_flag().
>
> And we need the additional SIGTRAP from handle_singlestep().
> And we have more problems with DEBUGCTLMSR_BTF. And we do
> not want access_process_vm() from uprobes code.
>
> So I think we need arch_uprobe_*able_step(struct uprobe_task *utask).
> Ignoring all problems except the one this patch tries to fix, x86
> can simply do:
>
> arch_uprobe_enble_step(utask, struct arch_uprobe *auprobe)
> {
> utask->clear_tf =
> !(regs->flags & X86_EFLAGS_TF) &&
> (auprobe->insn != "popf");
> regs->flags |= X86_EFLAGS_TF;
> }
>
> arch_uprobe_disable_step(utask)
> {
> if (utask->clear_tf)
> regs->flags &= ~X86_EFLAGS_TF;
> }
>
We were using something similar to this approach. [though we were still
using TIF_SINGLESTEP flag]. However this was all changed based on
feedback from Roland and Peter.
Here is the pointer to the discussion.
https://lkml.org/lkml/2011/1/27/283
> Fortunately, we can never race with gdb/enable_step(), and we do
> not care why X86_EFLAGS_TF was set, and we do not care about
> TIF_SINGLESTEP/TIF_FORCED_TF.
>
> However. This all needs more discussion (and help from Roland I guess).
>
> Sebastian, I think your patch is simple and certainly makes the things
> better, just it is not correct (you already realized you can't use
> uprobe->flags) and it is not arch-friendly.
>
> I'd suggest you to make 2 patches:
>
> - 1/2 creates arch_uprobe_*_step(...) __weak helpers in
> kernel/events/uprobes.c which simply call
> user_*_single_step() and updates the callers
>
> Not strictly necessary, but imho makes sense...
>
> - 2/2 adds the x86 implementation in arch/x86/kernel/uprobes.c
> which still uses user_*_single_step() but checks
> TIF_SINGLESTEP. As your patch does, but you should use
> utask, not uprobe.
>
> IOW, I simply suggest to make your patch x86-specific. Then we
> will try to do more fixes/improvements.
>
> Sebastian, Ananth, what do you think?
>
> Oleg.
>
next prev parent reply other threads:[~2012-07-31 5:23 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 [this message]
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
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=20120731052226.GA5087@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=ananth@in.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=roland@hack.frob.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.