On 07/26, Ananth N Mavinakayanahalli wrote:
>
> From: Ananth N Mavinakayanahalli <[email protected]>
>
> This is the port of uprobes to powerpc. Usage is similar to x86.
I am just curious why this series was ignored by powerpc maintainers...
Of course I can not review this code, I know nothing about powerpc,
but the patches look simple/straightforward.
Paul, Benjamin?
Just one question... Shouldn't arch_uprobe_pre_xol() forbid to probe
UPROBE_SWBP_INSN (at least) ?
(I assume that emulate_step() can't handle this case but of course I
do not understand arch/powerpc/lib/sstep.c)
Note that uprobe_pre_sstep_notifier() sets utask->state = UTASK_BP_HIT
without any checks. This doesn't look right if it was UTASK_SSTEP...
But again, I do not know what powepc will actually do if we try to
single-step over UPROBE_SWBP_INSN.
Oleg.
On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
> On 07/26, Ananth N Mavinakayanahalli wrote:
> >
> > From: Ananth N Mavinakayanahalli <[email protected]>
> >
> > This is the port of uprobes to powerpc. Usage is similar to x86.
>
> I am just curious why this series was ignored by powerpc maintainers...
Because it arrived too late for the previous merge window considering my
limited bandwidth for reviewing things and that nobody else seems to
have reviewed it :-)
It's still on track for the next one, and I'm hoping to dedicate most of
next week going through patches & doing a powerpc -next.
> Of course I can not review this code, I know nothing about powerpc,
> but the patches look simple/straightforward.
>
> Paul, Benjamin?
>
> Just one question... Shouldn't arch_uprobe_pre_xol() forbid to probe
> UPROBE_SWBP_INSN (at least) ?
>
> (I assume that emulate_step() can't handle this case but of course I
> do not understand arch/powerpc/lib/sstep.c)
>
> Note that uprobe_pre_sstep_notifier() sets utask->state = UTASK_BP_HIT
> without any checks. This doesn't look right if it was UTASK_SSTEP...
>
> But again, I do not know what powepc will actually do if we try to
> single-step over UPROBE_SWBP_INSN.
Ananth ?
Cheers,
Ben.
On Thu, Aug 16, 2012 at 07:41:53AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
> > On 07/26, Ananth N Mavinakayanahalli wrote:
> > >
> > > From: Ananth N Mavinakayanahalli <[email protected]>
> > >
> > > This is the port of uprobes to powerpc. Usage is similar to x86.
> >
> > I am just curious why this series was ignored by powerpc maintainers...
>
> Because it arrived too late for the previous merge window considering my
> limited bandwidth for reviewing things and that nobody else seems to
> have reviewed it :-)
>
> It's still on track for the next one, and I'm hoping to dedicate most of
> next week going through patches & doing a powerpc -next.
Thanks Ben!
> > Of course I can not review this code, I know nothing about powerpc,
> > but the patches look simple/straightforward.
> >
> > Paul, Benjamin?
> >
> > Just one question... Shouldn't arch_uprobe_pre_xol() forbid to probe
> > UPROBE_SWBP_INSN (at least) ?
> >
> > (I assume that emulate_step() can't handle this case but of course I
> > do not understand arch/powerpc/lib/sstep.c)
> >
> > Note that uprobe_pre_sstep_notifier() sets utask->state = UTASK_BP_HIT
> > without any checks. This doesn't look right if it was UTASK_SSTEP...
> >
> > But again, I do not know what powepc will actually do if we try to
> > single-step over UPROBE_SWBP_INSN.
>
> Ananth ?
set_swbp() will return -EEXIST to install_breakpoint if we are trying to
put a breakpoint on UPROBE_SWBP_INSN. So, the arch agnostic code itself
takes care of this case... or am I missing something?
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.
I will need to update the patches based on changes being made by Oleg
and Sebastien for the single-step issues. Will incorporate the powerpc
specific is_swbp_insn() change along with the changes required for the
single-step part and send out the next version.
Ananth
On 08/16, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Aug 16, 2012 at 07:41:53AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
> > > On 07/26, Ananth N Mavinakayanahalli wrote:
> > > >
> > > > From: Ananth N Mavinakayanahalli <[email protected]>
> > > >
> > > > This is the port of uprobes to powerpc. Usage is similar to x86.
> > >
> > > I am just curious why this series was ignored by powerpc maintainers...
> >
> > Because it arrived too late for the previous merge window considering my
> > limited bandwidth for reviewing things and that nobody else seems to
> > have reviewed it :-)
> >
> > It's still on track for the next one, and I'm hoping to dedicate most of
> > next week going through patches & doing a powerpc -next.
>
> Thanks Ben!
Great!
> > > Just one question... Shouldn't arch_uprobe_pre_xol() forbid to probe
> > > UPROBE_SWBP_INSN (at least) ?
> > >
> > > (I assume that emulate_step() can't handle this case but of course I
> > > do not understand arch/powerpc/lib/sstep.c)
> > >
> > > Note that uprobe_pre_sstep_notifier() sets utask->state = UTASK_BP_HIT
> > > without any checks. This doesn't look right if it was UTASK_SSTEP...
> > >
> > > But again, I do not know what powepc will actually do if we try to
> > > single-step over UPROBE_SWBP_INSN.
> >
> > Ananth ?
>
> set_swbp() will return -EEXIST to install_breakpoint if we are trying to
> put a breakpoint on UPROBE_SWBP_INSN.
not really, this -EEXIST (already removed by recent changes) means that
bp was already installed.
But this doesn't matter,
> 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).
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.
> 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.
Oleg.
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
On 08/17, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:
>
> > 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.
Yes, exactly. And we are going to single-step this saved uprobe->arch.insn,
even if gdb/whatever replaces the original insn later or already replaced.
So arch_uprobe_analyze_insn() should reject the "unsafe" instructions which
we can't step over safely.
> 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.
> 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().
However, find_active_uprobe()->is_swbp_at_addr()->is_swbp_insn() is
different, "true" confirms that this insn has triggered do_int3() and
thus we need send_sig(SIGTRAP) (just in case, this is not strictly
correct too but offtopic again).
We definitely need more changes/fixes/improvements in this area. And
perhaps powerpc requires more changes in the arch-neutral code, I dunno.
In particular, I think is_swbp_insn() should have a single caller,
is_swbp_at_addr(), and this caller should always play with current->mm.
And many, many other changes in the long term.
So far I think that, if powerpc really needs to change is_swbp_insn(),
it would be better to make another patch and discuss this change.
But of course I can't judge.
Oleg.
On Fri, Aug 17, 2012 at 05:00:31PM +0200, Oleg Nesterov wrote:
> On 08/17, Ananth N Mavinakayanahalli wrote:
> >
> > On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:
> >
> > > 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.
>
> Yes, exactly. And we are going to single-step this saved uprobe->arch.insn,
> even if gdb/whatever replaces the original insn later or already replaced.
>
> So arch_uprobe_analyze_insn() should reject the "unsafe" instructions which
> we can't step over safely.
Agreed.
> > 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.
> > 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.
> However, find_active_uprobe()->is_swbp_at_addr()->is_swbp_insn() is
> different, "true" confirms that this insn has triggered do_int3() and
> thus we need send_sig(SIGTRAP) (just in case, this is not strictly
> correct too but offtopic again).
>
> We definitely need more changes/fixes/improvements in this area. And
> perhaps powerpc requires more changes in the arch-neutral code, I dunno.
For powerpc, just having is_swbp_insn() (already a weak function) handle
the trap variants, should suffice.
> In particular, I think is_swbp_insn() should have a single caller,
> is_swbp_at_addr(), and this caller should always play with current->mm.
> And many, many other changes in the long term.
>
> So far I think that, if powerpc really needs to change is_swbp_insn(),
> it would be better to make another patch and discuss this change.
> But of course I can't judge.
OK. I will separate out the is_swbp_insn() change into a separate patch.
Ananth
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.
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