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: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	peterz@infradead.org, lkml <linux-kernel@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	Anton Blanchard <anton@samba.org>, Ingo Molnar <mingo@elte.hu>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
Date: Fri, 17 Aug 2012 10:43:07 +0530	[thread overview]
Message-ID: <20120817051307.GA4782@in.ibm.com> (raw)
In-Reply-To: <20120816152112.GA8874@redhat.com>

On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:

...

> > So, the arch agnostic code itself
> > takes care of this case...
> 
> Yes. I forgot about install_breakpoint()->is_swbp_insn() check which
> returns -ENOTSUPP, somehow I thought arch_uprobe_analyze_insn() does
> this.
> 
> > or am I missing something?
> 
> No, it is me.
> 
> > However, I see that we need a powerpc specific is_swbp_insn()
> > implementation since we will have to take care of all the trap variants.
> 
> Hmm, I am not sure. is_swbp_insn(insn), as it is used in the arch agnostic
> code, should only return true if insn == UPROBE_SWBP_INSN (just in case,
> this logic needs more fixes but this is offtopic).

I think it does...

> If powerpc has another insn(s) which can trigger powerpc's do_int3()
> counterpart, they should be rejected by arch_uprobe_analyze_insn().
> I think.

The insn that gets passed to arch_uprobe_analyze_insn() is copy_insn()'s
version, which is the file copy of the instruction. We should also take
care of the in-memory copy, in case gdb had inserted a breakpoint at the
same location, right? Updating is_swbp_insn() per-arch where needed will
take care of both the cases, 'cos it gets called before
arch_analyze_uprobe_insn() too.

> > I will need to update the patches based on changes being made by Oleg
> > and Sebastien for the single-step issues.
> 
> Perhaps you can do this in a separate change?
> 
> We need some (simple) changes in the arch agnostic code first, they
> should not break poweppc. These changes are still under discussion.
> Once we have "__weak  arch_uprobe_step*" you can reimplement these
> hooks and fix the problems with single-stepping.

OK. Agreed.

Ananth

WARNING: multiple messages have this Message-ID (diff)
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linuxppc-dev@lists.ozlabs.org,
	lkml <linux-kernel@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	Anton Blanchard <anton@samba.org>,
	michael@ellerman.id.au, Ingo Molnar <mingo@elte.hu>,
	peterz@infradead.org,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Subject: Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
Date: Fri, 17 Aug 2012 10:43:07 +0530	[thread overview]
Message-ID: <20120817051307.GA4782@in.ibm.com> (raw)
In-Reply-To: <20120816152112.GA8874@redhat.com>

On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:

...

> > So, the arch agnostic code itself
> > takes care of this case...
> 
> Yes. I forgot about install_breakpoint()->is_swbp_insn() check which
> returns -ENOTSUPP, somehow I thought arch_uprobe_analyze_insn() does
> this.
> 
> > or am I missing something?
> 
> No, it is me.
> 
> > However, I see that we need a powerpc specific is_swbp_insn()
> > implementation since we will have to take care of all the trap variants.
> 
> Hmm, I am not sure. is_swbp_insn(insn), as it is used in the arch agnostic
> code, should only return true if insn == UPROBE_SWBP_INSN (just in case,
> this logic needs more fixes but this is offtopic).

I think it does...

> If powerpc has another insn(s) which can trigger powerpc's do_int3()
> counterpart, they should be rejected by arch_uprobe_analyze_insn().
> I think.

The insn that gets passed to arch_uprobe_analyze_insn() is copy_insn()'s
version, which is the file copy of the instruction. We should also take
care of the in-memory copy, in case gdb had inserted a breakpoint at the
same location, right? Updating is_swbp_insn() per-arch where needed will
take care of both the cases, 'cos it gets called before
arch_analyze_uprobe_insn() too.

> > I will need to update the patches based on changes being made by Oleg
> > and Sebastien for the single-step issues.
> 
> Perhaps you can do this in a separate change?
> 
> We need some (simple) changes in the arch agnostic code first, they
> should not break poweppc. These changes are still under discussion.
> Once we have "__weak  arch_uprobe_step*" you can reimplement these
> hooks and fix the problems with single-stepping.

OK. Agreed.

Ananth


  reply	other threads:[~2012-08-17  5:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-26  5:19 [PATCH 1/2] powerpc: Add trap_nr to thread_struct Ananth N Mavinakayanahalli
2012-07-26  5:19 ` Ananth N Mavinakayanahalli
2012-07-26  5:20 ` [PATCH v3 2/2] powerpc: Uprobes port to powerpc Ananth N Mavinakayanahalli
2012-07-26  5:20   ` Ananth N Mavinakayanahalli
2012-07-27  8:40   ` Srikar Dronamraju
2012-07-27  8:40     ` Srikar Dronamraju
2012-08-15 16:59   ` Oleg Nesterov
2012-08-15 16:59     ` Oleg Nesterov
2012-08-15 21:41     ` Benjamin Herrenschmidt
2012-08-15 21:41       ` Benjamin Herrenschmidt
2012-08-16  5:00       ` Ananth N Mavinakayanahalli
2012-08-16  5:00         ` Ananth N Mavinakayanahalli
2012-08-16 15:21         ` Oleg Nesterov
2012-08-16 15:21           ` Oleg Nesterov
2012-08-17  5:13           ` Ananth N Mavinakayanahalli [this message]
2012-08-17  5:13             ` Ananth N Mavinakayanahalli
2012-08-17 15:00             ` Oleg Nesterov
2012-08-17 15:00               ` Oleg Nesterov
2012-08-21 11:24               ` Ananth N Mavinakayanahalli
2012-08-21 11:24                 ` Ananth N Mavinakayanahalli
2012-08-21 13:09                 ` Oleg Nesterov
2012-08-21 13:09                   ` Oleg Nesterov
2012-08-22  8:32                   ` Ananth N Mavinakayanahalli
2012-08-22  8:32                     ` Ananth N Mavinakayanahalli

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=20120817051307.GA4782@in.ibm.com \
    --to=ananth@in.ibm.com \
    --cc=anton@samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=paulus@samba.org \
    --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.