All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: ppcdev <linuxppc-dev@lists.ozlabs.org>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
Date: Wed, 20 Mar 2013 13:26:39 +0100	[thread overview]
Message-ID: <20130320122639.GA29541@redhat.com> (raw)
In-Reply-To: <20130320104033.GA19844@in.ibm.com>

Hi Ananth,

First of all, let me remind that I know nothing about powerpc ;)

But iirc we already discussed this a bit, I forgot the details but
still I have some concerns...

On 03/20, Ananth N Mavinakayanahalli wrote:
>
> GDB uses a variant of the trap instruction that is different from the
> one used by uprobes. Currently, running gdb on a program being traced
> by uprobes causes an endless loop since uprobes doesn't understand
> that the trap is inserted by some other entity and hence a SIGTRAP needs
> to be delivered.

Yes, and thus is_swbp_at_addr()->is_swbp_insn() called by handle_swbp()
should be updated,

> +bool is_swbp_insn(uprobe_opcode_t *insn)
> +{
> +	return (is_trap(*insn));
> +}

And this patch should fix the problem. (and probably this is fine
for prepare_uprobe()).


But, at the same time, is the new definition fine for verify_opcode()?

IOW, powerpc has another is_trap() insn(s) used by gdb, lets denote it X.
X != UPROBE_SWBP_INSN.

Suppose that gdb installs the trap X at some addr, and then uprobe_register()
tries to install uprobe at the same address. Then set_swbp() will do nothing,
assuming the uprobe was already installed.

But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
verify. If not, we need 2 definitions. is_uprobe_insn() should still check
insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap().

And I am just curious, could you explain how X and UPROBE_SWBP_INSN
differ?

Oleg.

  reply	other threads:[~2013-03-20 12:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 10:40 [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints Ananth N Mavinakayanahalli
2013-03-20 12:26 ` Oleg Nesterov [this message]
2013-03-20 12:43   ` Oleg Nesterov
2013-03-20 15:42     ` Ananth N Mavinakayanahalli
2013-03-20 16:07       ` Oleg Nesterov
2013-03-21  7:17         ` Ananth N Mavinakayanahalli
2013-03-21 16:00           ` Oleg Nesterov
2013-03-22  4:37             ` Ananth N Mavinakayanahalli
2013-03-20 15:41   ` Ananth N Mavinakayanahalli
2013-03-20 16:06     ` Oleg Nesterov
2013-03-21  7:15       ` Ananth N Mavinakayanahalli
2013-03-21 15:58         ` Oleg Nesterov
2013-03-22  4:47           ` Ananth N Mavinakayanahalli
2013-03-22 14:46             ` 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=20130320122639.GA29541@redhat.com \
    --to=oleg@redhat.com \
    --cc=ananth@in.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=stable@vger.kernel.org \
    /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.