Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
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 > > > > > > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
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 > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote: > On 07/26, Ananth N Mavinakayanahalli wrote: > > > > From: Ananth N Mavinakayanahalli > > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
On 07/26, Ananth N Mavinakayanahalli wrote: > > From: Ananth N Mavinakayanahalli > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] powerpc: Uprobes port to powerpc
* Ananth N Mavinakayanahalli [2012-07-26 10:50:29]: > From: Ananth N Mavinakayanahalli > > This is the port of uprobes to powerpc. Usage is similar to x86. > > [root@ ~]# ./bin/perf probe -x /lib64/libc.so.6 malloc > Added new event: > probe_libc:malloc(on 0xb4860) > > You can now use it in all perf tools, such as: > > perf record -e probe_libc:malloc -aR sleep 1 > > [root@ ~]# ./bin/perf record -e probe_libc:malloc -aR sleep 20 > [ perf record: Woken up 22 times to write data ] > [ perf record: Captured and wrote 5.843 MB perf.data (~255302 samples) ] > [root@ ~]# ./bin/perf report --stdio > ... > > # Samples: 83K of event 'probe_libc:malloc' > # Event count (approx.): 83484 > # > # Overhead Command Shared Object Symbol > # . .. > # > 69.05% tar libc-2.12.so [.] malloc > 28.57%rm libc-2.12.so [.] malloc > 1.32% avahi-daemon libc-2.12.so [.] malloc > 0.58% bash libc-2.12.so [.] malloc > 0.28% sshd libc-2.12.so [.] malloc > 0.08%irqbalance libc-2.12.so [.] malloc > 0.05% bzip2 libc-2.12.so [.] malloc > 0.04% sleep libc-2.12.so [.] malloc > 0.03%multipathd libc-2.12.so [.] malloc > 0.01% sendmail libc-2.12.so [.] malloc > 0.01% automount libc-2.12.so [.] malloc > > Patch applies on the current master branch of Linus' tree (bdc0077af). > The trap_nr addition patch is a prereq. > > Signed-off-by: Ananth N Mavinakayanahalli Acked-by: Srikar Dronamraju -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
