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: 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: Tue, 21 Aug 2012 15:09:30 +0200	[thread overview]
Message-ID: <20120821130930.GA10382@redhat.com> (raw)
In-Reply-To: <20120821112433.GB3519@in.ibm.com>

On 08/21, Ananth N Mavinakayanahalli wrote:
>
> On Fri, Aug 17, 2012 at 05:00:31PM +0200, Oleg Nesterov wrote:
>
> > > We should also take
> > > care of the in-memory copy, in case gdb had inserted a breakpoint at the
> > > same location, right?
> >
> > gdb (or even the application itself) and uprobes can obviously confuse
> > each other, in many ways, and we can do nothing at least currently.
> > Just we should ensure that the kernel can't crash/hang/etc.
>
> Absolutely. The proper fix for this at least from a breakpoint insertion
> perspective is to educate gdb (possibly ptrace itself) to fail on a
> breakpoint insertion request on an already existing one.

Oh, I don't think this is possible. And there are other problems like
this. Uprobe can confuse gdb too, in many ways. For example,
uprobe_register() can wrongly _remove_ int3 installed by gdb.

The proper fix, I think, is to rework the whole idea about uprobe bps,
but this is really "in the long term". install_breakpoint() should
only unmap the page and mark its pte as "owned by kernel, FOLL_WRITE
should not work". Something like migration or PROT_NONE. The task
itself should install bp during the page fault. And we need the
"backing store" for the pages with uprobes. Yes, this all is very
vague and I can be wrong.

Anyway, this is relatively minor, we have more serious problems.

> > > 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.
> >
> > For example. set_swbp()->is_swbp_insn() == T means that (for example)
> > uprobe_register() and uprobe_mmap() raced with each other and there is
> > no need for set_swbp().
>
> 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.

WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Ananth N Mavinakayanahalli <ananth@in.ibm.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: Tue, 21 Aug 2012 15:09:30 +0200	[thread overview]
Message-ID: <20120821130930.GA10382@redhat.com> (raw)
In-Reply-To: <20120821112433.GB3519@in.ibm.com>

On 08/21, Ananth N Mavinakayanahalli wrote:
>
> On Fri, Aug 17, 2012 at 05:00:31PM +0200, Oleg Nesterov wrote:
>
> > > We should also take
> > > care of the in-memory copy, in case gdb had inserted a breakpoint at the
> > > same location, right?
> >
> > gdb (or even the application itself) and uprobes can obviously confuse
> > each other, in many ways, and we can do nothing at least currently.
> > Just we should ensure that the kernel can't crash/hang/etc.
>
> Absolutely. The proper fix for this at least from a breakpoint insertion
> perspective is to educate gdb (possibly ptrace itself) to fail on a
> breakpoint insertion request on an already existing one.

Oh, I don't think this is possible. And there are other problems like
this. Uprobe can confuse gdb too, in many ways. For example,
uprobe_register() can wrongly _remove_ int3 installed by gdb.

The proper fix, I think, is to rework the whole idea about uprobe bps,
but this is really "in the long term". install_breakpoint() should
only unmap the page and mark its pte as "owned by kernel, FOLL_WRITE
should not work". Something like migration or PROT_NONE. The task
itself should install bp during the page fault. And we need the
"backing store" for the pages with uprobes. Yes, this all is very
vague and I can be wrong.

Anyway, this is relatively minor, we have more serious problems.

> > > 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.
> >
> > For example. set_swbp()->is_swbp_insn() == T means that (for example)
> > uprobe_register() and uprobe_mmap() raced with each other and there is
> > no need for set_swbp().
>
> 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.


  reply	other threads:[~2012-08-21 13:13 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 [this message]
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=20120821130930.GA10382@redhat.com \
    --to=oleg@redhat.com \
    --cc=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=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.