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: Wed, 22 Aug 2012 14:02:25 +0530	[thread overview]
Message-ID: <20120822083224.GC29216@in.ibm.com> (raw)
In-Reply-To: <20120821130930.GA10382@redhat.com>

On Tue, Aug 21, 2012 at 03:09:30PM +0200, Oleg Nesterov wrote:

...

> > This is true for Intel like architectures that have *one* swbp
> > instruction. On Powerpc, gdb for instance, can insert a trap variant at
> > the address. Therefore, is_swbp_insn() by definition should return true
> > for all trap variants.
> 
> Not in this case, I think.
> 
> OK, I was going to do this later, but this discussion makes me think
> I should try to send the patch sooner.
> 
> set_swbp()->is_swbp_at_addr() is simply unneeded and in fact should
> be considered as unnecessary pessimization.
> 
> set_orig_insn()->is_swbp_at_addr() makes more sense, but it can't fix
> all races with userpace. Still it should die.
> 
> > OK. I will separate out the is_swbp_insn() change into a separate patch.
> 
> Great thanks. And if we remove is_swbp_insn() from set_swbp() and
> set_orig_insn() then the semantics of is_swbp_insn() will much more
> clear, and in this case I powerpc probably really needs to change it.

Oleg,

I have posted a new version for review [1] without the is_swbp_insn()
change. I will await your changes around is_swbp_at_addr() and make
changes to the powerpc code if necessary.

Regards,
Ananth

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-August/100524.html

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: Wed, 22 Aug 2012 14:02:25 +0530	[thread overview]
Message-ID: <20120822083224.GC29216@in.ibm.com> (raw)
In-Reply-To: <20120821130930.GA10382@redhat.com>

On Tue, Aug 21, 2012 at 03:09:30PM +0200, Oleg Nesterov wrote:

...

> > This is true for Intel like architectures that have *one* swbp
> > instruction. On Powerpc, gdb for instance, can insert a trap variant at
> > the address. Therefore, is_swbp_insn() by definition should return true
> > for all trap variants.
> 
> Not in this case, I think.
> 
> OK, I was going to do this later, but this discussion makes me think
> I should try to send the patch sooner.
> 
> set_swbp()->is_swbp_at_addr() is simply unneeded and in fact should
> be considered as unnecessary pessimization.
> 
> set_orig_insn()->is_swbp_at_addr() makes more sense, but it can't fix
> all races with userpace. Still it should die.
> 
> > OK. I will separate out the is_swbp_insn() change into a separate patch.
> 
> Great thanks. And if we remove is_swbp_insn() from set_swbp() and
> set_orig_insn() then the semantics of is_swbp_insn() will much more
> clear, and in this case I powerpc probably really needs to change it.

Oleg,

I have posted a new version for review [1] without the is_swbp_insn()
change. I will await your changes around is_swbp_at_addr() and make
changes to the powerpc code if necessary.

Regards,
Ananth

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-August/100524.html


  reply	other threads:[~2012-08-22  8:32 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
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 [this message]
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=20120822083224.GC29216@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.