All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	Anton Arapov <anton@redhat.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] uprobes: Kill set_swbp()->is_swbp_at_addr()
Date: Mon, 24 Sep 2012 14:38:58 +0530	[thread overview]
Message-ID: <20120924090858.GA2248@in.ibm.com> (raw)
In-Reply-To: <20120923201945.GA27446@redhat.com>

On Sun, Sep 23, 2012 at 10:19:45PM +0200, Oleg Nesterov wrote:
> A separate patch for better documentation.
> 
> set_swbp()->is_swbp_at_addr() is not needed for correctness, it is
> harmless to do the unnecessary __replace_page(old_page, new_page)
> when these 2 pages are identical.
> 
> And it can not be counted as optimization. mmap/register races are
> very unlikely, while in the likely case is_swbp_at_addr() adds the
> extra get_user_pages() even if the caller is uprobe_mmap(current->mm)
> and returns false.
> 
> Note also that the semantics/usage of is_swbp_at_addr() in uprobe.c
> is confusing. set_swbp() uses it to detect the case when this insn
> was already modified by uprobes, that is why it should always compare
> the opcode with UPROBE_SWBP_INSN even if the hardware (like powerpc)
> has other trap insns.

Agreed...

> It doesn't matter if this "int3" was in fact
> installed by gdb or application itself, we are going to "steal" this
> breakpoint anyway and execute the original insn from vm_file even if
> it no longer matches the memory.

Wouldn't this text make more sense:

It doesn't matter if this 'breakpoint' was in fact...

'int3' is still an x86 artifact.

On powerpc, we don't even get to install_breakpoint() ->set_swbp()
->is_swbp_at_addr() because arch_uprobe_analyze_insn() would've already
caused install_breakpoint() to return -ENOTSUPP.

> OTOH, handle_swbp()->find_active_uprobe() uses is_swbp_at_addr() to
> figure out whether we need to send SIGTRAP or not if we can not find
> uprobe, so in this case it should return true for all trap variants,
> not only for UPROBE_SWBP_INSN.

So, we will need a powerpc specific is_swbp_insn()... ok.

Ananth


  parent reply	other threads:[~2012-09-24  9:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-23 20:19 [PATCH 0/4] uprobes: remove is_swbp_at_addr() from register/unregister Oleg Nesterov
2012-09-23 20:19 ` [PATCH 1/4] uprobes: Kill set_swbp()->is_swbp_at_addr() Oleg Nesterov
2012-09-24  9:03   ` Peter Zijlstra
2012-09-24 15:23     ` Oleg Nesterov
2012-09-24  9:08   ` Ananth N Mavinakayanahalli [this message]
2012-09-24 16:02     ` Oleg Nesterov
2012-10-06  6:55   ` Srikar Dronamraju
2012-09-23 20:19 ` [PATCH 2/4] uprobes: Introduce copy_opcode(), kill read_opcode() Oleg Nesterov
2012-10-06  6:59   ` Srikar Dronamraju
2012-09-23 20:19 ` [PATCH 3/4] uprobes: Kill set_orig_insn()->is_swbp_at_addr() Oleg Nesterov
2012-09-24  9:13   ` Peter Zijlstra
2012-09-24 15:23     ` Oleg Nesterov
2012-10-06  7:18   ` Srikar Dronamraju
2012-09-23 20:19 ` [PATCH 4/4] uprobes: Simplify is_swbp_at_addr(), remove stale comments Oleg Nesterov
2012-10-06  7:11   ` Srikar Dronamraju

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=20120924090858.GA2248@in.ibm.com \
    --to=ananth@in.ibm.com \
    --cc=anton@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --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.