On Fri, Aug 24, 2012 at 05:07:31PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2012-08-24 at 11:13 +1000, Michael Ellerman wrote:
> >
> > Yeah. A NULL regs here is a kernel bug, so I think it's actually
> > preferable to crash than silently return.
>
> Or best, if you think there's a remote
On Fri, 2012-08-24 at 11:13 +1000, Michael Ellerman wrote:
>
> Yeah. A NULL regs here is a kernel bug, so I think it's actually
> preferable to crash than silently return.
Or best, if you think there's a remote chance that the bug might hit:
if (WARN(!regs))
return
On Fri, 2012-08-24 at 11:13 +1000, Michael Ellerman wrote:
Yeah. A NULL regs here is a kernel bug, so I think it's actually
preferable to crash than silently return.
Or best, if you think there's a remote chance that the bug might hit:
if (WARN(!regs))
return
On Fri, Aug 24, 2012 at 05:07:31PM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-24 at 11:13 +1000, Michael Ellerman wrote:
Yeah. A NULL regs here is a kernel bug, so I think it's actually
preferable to crash than silently return.
Or best, if you think there's a remote chance
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
> >
> > These seem to be duplicated in kprobes.h, can we consolidate them.
> >
> > > +struct arch_uprobe {
> > > + u8 insn[MAX_UINSN_BYTES];
> > > +};
> >
> > Why not uprobe_opcode_t insn ?
> >
>
> insn is updated/accessed in
On Thu, 2012-08-23 at 11:28 +0530, Ananth N Mavinakayanahalli wrote:
> On Thu, Aug 23, 2012 at 02:28:20PM +1000, Michael Ellerman wrote:
> > On Wed, 2012-08-22 at 13:57 +0530, Ananth N Mavinakayanahalli wrote:
> > > From: Ananth N Mavinakayanahalli
> > >
> > > This is the port of uprobes to
On Thu, 2012-08-23 at 21:47 +0530, Srikar Dronamraju wrote:
> * Benjamin Herrenschmidt [2012-08-23 20:06:18]:
>
> > On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
> > > >
> > >
> > > insn is updated/accessed in the arch independent code. Size of
> > > uprobe_opcode_t could be
* Benjamin Herrenschmidt [2012-08-23 20:06:18]:
> On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
> > >
> >
> > insn is updated/accessed in the arch independent code. Size of
> > uprobe_opcode_t could be different for different archs.
> > uprobe_opcode_t
> > represents the size of
* Oleg Nesterov [2012-08-23 11:02:09]:
> On 08/23, Benjamin Herrenschmidt wrote:
> >
> > On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
> > > >
> > >
> > > insn is updated/accessed in the arch independent code. Size of
> > > uprobe_opcode_t could be different for different archs.
>
On 08/23, Benjamin Herrenschmidt wrote:
>
> On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
> > >
> >
> > insn is updated/accessed in the arch independent code. Size of
> > uprobe_opcode_t could be different for different archs.
> > uprobe_opcode_t
> > represents the size of the
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
> >
>
> insn is updated/accessed in the arch independent code. Size of
> uprobe_opcode_t could be different for different archs.
> uprobe_opcode_t
> represents the size of the smallest breakpoint instruction for an
> arch.
>
> Hence u8
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for different archs.
uprobe_opcode_t
represents the size of the smallest breakpoint instruction for an
arch.
Hence u8 works out
On 08/23, Benjamin Herrenschmidt wrote:
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for different archs.
uprobe_opcode_t
represents the size of the smallest breakpoint
* Oleg Nesterov o...@redhat.com [2012-08-23 11:02:09]:
On 08/23, Benjamin Herrenschmidt wrote:
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for different archs.
* Benjamin Herrenschmidt b...@kernel.crashing.org [2012-08-23 20:06:18]:
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for different archs.
uprobe_opcode_t
represents
On Thu, 2012-08-23 at 21:47 +0530, Srikar Dronamraju wrote:
* Benjamin Herrenschmidt b...@kernel.crashing.org [2012-08-23 20:06:18]:
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could
On Thu, 2012-08-23 at 11:28 +0530, Ananth N Mavinakayanahalli wrote:
On Thu, Aug 23, 2012 at 02:28:20PM +1000, Michael Ellerman wrote:
On Wed, 2012-08-22 at 13:57 +0530, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
This is the port of uprobes to
On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
These seem to be duplicated in kprobes.h, can we consolidate them.
+struct arch_uprobe {
+ u8 insn[MAX_UINSN_BYTES];
+};
Why not uprobe_opcode_t insn ?
insn is updated/accessed in the arch independent
On Thu, Aug 23, 2012 at 02:28:20PM +1000, Michael Ellerman wrote:
> On Wed, 2012-08-22 at 13:57 +0530, Ananth N Mavinakayanahalli wrote:
> > From: Ananth N Mavinakayanahalli
> >
> > This is the port of uprobes to powerpc. Usage is similar to x86.
>
> Hi Ananth,
>
> Excuse my ignorance of
>
> These seem to be duplicated in kprobes.h, can we consolidate them.
>
> > +struct arch_uprobe {
> > + u8 insn[MAX_UINSN_BYTES];
> > +};
>
> Why not uprobe_opcode_t insn ?
>
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for
On Wed, 2012-08-22 at 13:57 +0530, Ananth N Mavinakayanahalli wrote:
> From: Ananth N Mavinakayanahalli
>
> This is the port of uprobes to powerpc. Usage is similar to x86.
Hi Ananth,
Excuse my ignorance of uprobes, some comments inline ...
> [root@ ~]# ./bin/perf probe -x
On 08/22, Ananth N Mavinakayanahalli wrote:
>
> +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
> *mm, unsigned long addr)
> +{
> + unsigned int insn;
> +
> + if (addr & 0x03)
> + return -EINVAL;
> +
> + memcpy(, auprobe->insn, MAX_UINSN_BYTES);
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
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
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
On 08/22, Ananth N Mavinakayanahalli wrote:
+int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
*mm, unsigned long addr)
+{
+ unsigned int insn;
+
+ if (addr 0x03)
+ return -EINVAL;
+
+ memcpy(insn, auprobe-insn, MAX_UINSN_BYTES);
+
On Wed, 2012-08-22 at 13:57 +0530, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
This is the port of uprobes to powerpc. Usage is similar to x86.
Hi Ananth,
Excuse my ignorance of uprobes, some comments inline ...
[root@ ~]# ./bin/perf probe -x
These seem to be duplicated in kprobes.h, can we consolidate them.
+struct arch_uprobe {
+ u8 insn[MAX_UINSN_BYTES];
+};
Why not uprobe_opcode_t insn ?
insn is updated/accessed in the arch independent code. Size of
uprobe_opcode_t could be different for different archs.
On Thu, Aug 23, 2012 at 02:28:20PM +1000, Michael Ellerman wrote:
On Wed, 2012-08-22 at 13:57 +0530, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
This is the port of uprobes to powerpc. Usage is similar to x86.
Hi Ananth,
Excuse my ignorance of
28 matches
Mail list logo
