linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
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: Wed, 1 Aug 2012 15:43:37 +0200	[thread overview]
Message-ID: <20120801134337.GA3923@redhat.com> (raw)
In-Reply-To: <1343735548-18101-2-git-send-email-bigeasy@linutronix.de>

See my previous emails... and a couple of other nits.

On 07/31, Sebastian Andrzej Siewior wrote:
>
> +static int insn_is_popf(const u8 *insn)
> +{
> +	/* popf */
> +	if (insn[0] == 0x9d)
> +		return 1;
> +	return 0;
> +}

I can't believe I am going to blame the naming ;)

But "insn_is_popf" looks confusing, imho. Yes, currently "iret" can't
be probed, so (afaics) we only need to check "popf". Still I think the
name should be generic, and the comment should explain that only "popf"
can be probed. And I think it would be better to pass auprobe, not
->insn. But this all is cosmetic.

> +void arch_uprobe_enable_step(struct task_struct *child,
> +		struct arch_uprobe *auprobe)
> +{
> +	struct uprobe_task	*utask		= child->utask;
> +	struct arch_uprobe_task	*autask		= &utask->autask;
> +	struct pt_regs		*regs		= task_pt_regs(child);
> +	unsigned long		debugctl;
> +
> +	autask->restore_flags = 0;
> +	if (!(regs->flags & X86_EFLAGS_TF) &&
> +			!insn_is_popf(auprobe->insn)) {
> +		autask->restore_flags |= UPROBE_CLEAR_TF;

This looks correct, but

> +		debugctl = get_debugctlmsr();
> +		if (debugctl & DEBUGCTLMSR_BTF) {

No, I don't think "X86_EFLAGS_TF && !insn_is_popf" is right. I guess
this mimics "enable_single_step(child) && block" in enable_step(), but
we can't trust insn_is_popf(), we should check/clear DEBUGCTLMSR_BTF
unconditionally.

And get_debugctlmsr() is another reason why arch_uprobe_enable_step()
should not have "struct task_struct *child" argument, otherwise the
code looks confusing.

However, I am not sure we can trust it. We are in kernel mode,
DEBUGCTLMSR_BTF can be cleared by kprobes (Ananth, please correct me).
I think we need to check TIF_BLOCKSTEP.

Oleg.


  parent reply	other threads:[~2012-08-01 13:46 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
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         ` Oleg Nesterov [this message]
2012-08-02  4:58           ` [PATCH 2/2] x86/uprobes: implement x86 specific arch_uprobe_*_step 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=20120801134337.GA3923@redhat.com \
    --to=oleg@redhat.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=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 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).