On 2/4/21 4:19 PM, Ravi Bangoria wrote:
On 2/4/21 4:17 PM, Ravi Bangoria wrote:
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Uprobe on such prefixed instruction as well.
There are two ways prob
eturned 0 which says 'did not emulate, may
have to single-step'.
Fixes: 930d6288a26787 ("powerpc: sstep: Add support for maddhd, maddhdu, maddld
instructions")
Signed-off-by: Ananth N Mavinakayanahalli
Suggested-by: Michael Ellerman
Tested-by: Naveen N. Rao
Reviewed-by:
We currently unconditionally try to emulate newer instructions on older
Power versions that could cause issues. Gate it.
Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction
emulation code")
Signed-off-by: Ananth N Mavinakayanahalli
---
[v4] Based on feedback
On 1/23/21 6:03 AM, Michael Ellerman wrote:
Ananth N Mavinakayanahalli writes:
We currently just percolate the return value from analyze_instr()
to the caller of emulate_step(), especially if it is a -1.
For one particular case (opcode = 4) for instructions that
aren't currently emulate
eturned 0 which says
'did not emulate, may have to single-step'.
Signed-off-by: Ananth N Mavinakayanahalli
Tested-by: Naveen N. Rao
---
arch/powerpc/lib/sstep.c | 49 +-
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/arch/p
We currently unconditionally try to emulate newer instructions on older
Power versions that could cause issues. Gate it.
Signed-off-by: Ananth N Mavinakayanahalli
---
[v3] Addressed Naveen's comments on scv and addpcis
[v2] Fixed description
arch/powerpc/lib/sstep.c |
On 1/20/21 3:44 PM, Naveen N. Rao wrote:
On 2021/01/20 03:16PM, Ananth N Mavinakayanahalli wrote:
...
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index bf7a7d62ae8b..ed119858e5e9 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1528,6 +1528,8
We currently unconditionally try to emulate newer instructions on older
Power versions that could cause issues. Gate it.
Signed-off-by: Ananth N Mavinakayanahalli
---
arch/powerpc/lib/sstep.c | 40
1 file changed, 40 insertions(+)
diff --git a/arch
We currently unconditionally try to newer emulate instructions on older
Power versions that could cause issues. Gate it.
Signed-off-by: Ananth N Mavinakayanahalli
---
arch/powerpc/lib/sstep.c | 40
1 file changed, 40 insertions(+)
diff --git a/arch
On 10/5/20 9:42 AM, Mahesh Salgaonkar wrote:
Every error log reported by OPAL is exported to userspace through a sysfs
interface and notified using kobject_uevent(). The userspace daemon
(opal_errd) then reads the error log and acknowledges it error log is saved
safely to disk. Once acknowledged
On Thu, Aug 09, 2018 at 06:02:53PM +1000, Nicholas Piggin wrote:
> On Thu, 09 Aug 2018 16:34:07 +1000
> Michael Ellerman wrote:
>
> > "Aneesh Kumar K.V" writes:
> > > On 08/08/2018 08:26 PM, Michael Ellerman wrote:
> > >> Mahesh J Salgaonkar writes:
> > >>> From: Mahesh Salgaonkar
> > >>>
gt; (kprobe_handler() or optimized_callback()).
>
> Reported-by: Michael Ellerman
> Signed-off-by: Naveen N. Rao
Acked-by: Ananth N Mavinakayanahalli
k pointer from memory using lwz,
> effectively loading a corrupt (32bit) address, causing the kernel crash.
>
> Fix this by loading the 64bit value instead.
>
> Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of
> emulate_step()")
> Signed-off-by: Ravi Bangoria
> Reviewed-by: Naveen N. Rao
Reviewed-by: Ananth N Mavinakayanahalli
On Wed, Feb 22, 2017 at 07:23:38PM +0530, Naveen N. Rao wrote:
> With ABIv2, we offset 8 bytes into a function to get at the local entry
> point.
>
Looks good.
> Signed-off-by: Naveen N. Rao
Acked-by: Ananth N Mavinakayanahalli
On Wed, Feb 15, 2017 at 12:28:34AM +0530, Naveen N. Rao wrote:
> Allow kprobes to be placed on ftrace _mcount() call sites. This
> optimization avoids the use of a trap, by riding on ftrace
> infrastructure.
>
> This depends on HAVE_DYNAMIC_FTRACE_WITH_REGS which depends on
> MPROFILE_KERNEL, whic
;
> Signed-off-by: Naveen N. Rao
Acked-by: Ananth N Mavinakayanahalli
On Tue, Feb 14, 2017 at 02:08:02PM +0530, Naveen N. Rao wrote:
> This helper will be used in a subsequent patch to emulate instructions
> on re-entering the kprobe handler. No functional change.
>
> Signed-off-by: Naveen N. Rao
Acked-by: Ananth N Mavinakayanahalli
> c00d04c8 k _do_fork+0x8[DISABLED]
> c00d04d0 k _do_fork+0x10[DISABLED]
> c00412b0 k kretprobe_trampoline+0x0[OPTIMIZED]
>
> Signed-off-by: Naveen N. Rao
Acked-by: Ananth N Mavinakayanahalli
ename post_kprobe_handler() to kprobe_post_handler() for
> more uniform naming.
>
> Reported-by: Masami Hiramatsu
> Signed-off-by: Naveen N. Rao
Acked-by: Ananth N Mavinakayanahalli
On Wed, Apr 06, 2016 at 06:02:57PM +0530, Naveen N. Rao wrote:
> + if (!pev->uprobes && map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS)
> tev->point.offset += PPC64LE_LEP_OFFSET;
uprobes check against kallsysms? Am I missing something here?
Ananth
_
adjust all the symbols during symbol table load,
> but only adjust the probe trace point.
>
> Cc: Mark Wielaard
> Cc: Thiago Jung Bauermann
> Cc: Ananth N Mavinakayanahalli
> Cc: Arnaldo Carvalho de Melo
> Cc: Masami Hiramatsu
> Reported-by: Michael Ellerman
> Sig
On Tue, Sep 08, 2015 at 07:24:39PM +1000, Michael Ellerman wrote:
> On Wed, 2015-09-02 at 10:39 +0530, Ananth N Mavinakayanahalli wrote:
> > On Tue, Sep 01, 2015 at 10:29:12PM -0500, Scott Wood wrote:
> >
> > > Why is this selected by KVM on PPC if KVM on PPC doesn'
On Tue, Sep 01, 2015 at 10:29:12PM -0500, Scott Wood wrote:
> On Wed, 2015-09-02 at 08:07 +0530, Ananth N Mavinakayanahalli wrote:
> > On Tue, Sep 01, 2015 at 07:03:12PM -0500, Scott Wood wrote:
> > > On Tue, 2015-09-01 at 12:11 +0530, Ananth N Mavinakayanahalli wrote:
> >
On Tue, Sep 01, 2015 at 07:03:12PM -0500, Scott Wood wrote:
> On Tue, 2015-09-01 at 12:11 +0530, Ananth N Mavinakayanahalli wrote:
> > On Mon, Aug 31, 2015 at 08:35:17PM +1000, Michael Ellerman wrote:
> > > On Tue, 2015-25-08 at 05:41:10 UTC, Ananth N Mavinakayanahalli wrote
On Mon, Aug 31, 2015 at 08:35:17PM +1000, Michael Ellerman wrote:
> On Tue, 2015-25-08 at 05:41:10 UTC, Ananth N Mavinakayanahalli wrote:
> > Add user return notifier support for powerpc. Similar to x86, this feature
> > keys off of the KVM Kconfig.
>
> Please flesh this out.
Add user return notifier support for powerpc. Similar to x86, this feature
keys off of the KVM Kconfig.
Signed-off-by: Ananth N Mavinakayanahalli
---
Documentation/features/debug/user-ret-profiler/arch-support.txt |2 +-
arch/powerpc/Kconfig|1
On Tue, Jul 21, 2015 at 12:53:07PM +1000, Michael Ellerman wrote:
> On Sun, 2015-07-19 at 11:21 +0900, Masami Hiramatsu wrote:
> > On 2015/07/16 19:56, Ananth N Mavinakayanahalli wrote:
> > > Kprobes uses a breakpoint instruction to trap into execution flow
> > > an
had with a direct
jump instead of a breakpoint, but the caveats need to be traded off
with the complexity it brings in.
For now, mark OPTPROBES na for powerpc.
Signed-off-by: Ananth N Mavinakayanahalli
---
.../features/debug/optprobes/arch-support.txt |2 +-
1 file changed, 1 insertion
To be used for features we will not support on a particular architecture.
The git log that adds this needs to provide the justification 'why?'
Signed-off-by: Ananth N Mavinakayanahalli
---
Documentation/features/arch-support.txt |1 +
1 file changed, 1 insertion(+)
di
On Sun, Jul 19, 2015 at 11:21:50AM +0900, Masami Hiramatsu wrote:
> On 2015/07/16 19:56, Ananth N Mavinakayanahalli wrote:
> > Kprobes uses a breakpoint instruction to trap into execution flow
> > and the probed instruction is single-stepped from an alternate location.
&
: Ananth N Mavinakayanahalli
---
.../features/debug/optprobes/arch-support.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/features/debug/optprobes/arch-support.txt
b/Documentation/features/debug/optprobes/arch-support.txt
index b8999d8..73662f9
To be used for features we will not support on a particular architecture.
The git log that adds this needs to provide the justification 'why?'
Signed-off-by: Ananth N Mavinakayanahalli
---
Documentation/features/arch-support.txt |1 +
1 file changed, 1 insertion(+)
di
-by: Ananth N Mavinakayanahalli
---
.../features/debug/optprobes/arch-support.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/features/debug/optprobes/arch-support.txt
b/Documentation/features/debug/optprobes/arch-support.txt
index b8999d8..0a3ca33
lazy pattern.
> > Error: Command Parse Error.
> >
> > Fix this by checking the probe pattern in more detail.
>
> Masami, can I have your Acked-by or Reviewed-by?
Arnaldo,
FWIW, I have reviewed this code...
Reviewed-by: Ananth N Mavinakayanahalli
>
&
| 57 --
> tools/perf/util/symbol-elf.c | 11 -
> tools/perf/util/symbol.c | 6 +++
> 9 files changed, 170 insertions(+), 30 deletions(-)
> create mode 100644 tools/perf/arch/powerpc/util/elf-sym-decode.c
> create
and applying it won't break other arch users, but having a/rev-by from
> ppc developers should speed up this process.
Hi Arnaldo,
Yes, I have reviewed the patches. So, for all patches...
Reviewed-by: Ananth N Mavinakayanahalli
___
Lin
On Thu, May 08, 2014 at 02:40:00PM +0900, Masami Hiramatsu wrote:
> (2014/05/08 13:47), Ananth N Mavinakayanahalli wrote:
> > On Wed, May 07, 2014 at 08:55:51PM +0900, Masami Hiramatsu wrote:
> >
> > ...
> >
> >> +#if defined(CONFIG_PPC64) &
On Wed, May 07, 2014 at 08:55:51PM +0900, Masami Hiramatsu wrote:
...
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> +/*
> + * On PPC64 ABIv1 the function pointer actually points to the
> + * function's descriptor. The first entry in the descriptor is the
> + * address
On Wed, Feb 26, 2014 at 10:23:01AM +0800, Liu Ping Fan wrote:
> The branch target should be the func addr, not the addr of func_descr_t.
> So using ppc_function_entry() to generate the right target addr.
>
> Signed-off-by: Liu Ping Fan
> ---
> This bug will make ftrace fail to work. It can be tri
On Mon, Sep 09, 2013 at 03:20:58PM -0500, Tom Musta wrote:
> > > Isn't that code occasionally used with uprobes too nowadays ?
> >
> > Yes. I believe so.
>
> I'm going to back-pedal a little. I reread code and can connect
> single step code to kprobes but not necessarily to uprobes. So
> I am n
On Tue, Apr 23, 2013 at 03:32:30PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-04-23 at 10:35 +0530, Ananth N Mavinakayanahalli wrote:
> > On Tue, Apr 23, 2013 at 10:40:10AM +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrot
On Tue, Apr 23, 2013 at 10:40:10AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2013-04-19 at 17:14 +0530, Vasant Hegde wrote:
> > Add new return code to rtas_flash to indicate firmware entitlement
> > expiry. This will be used by the update_flash script to return
> > appropriate message to the u
From: Ananth N Mavinakayanahalli
prepare_uprobe() already checks if the underlying unstruction
(on file) is a trap variant. We don't need to check this again.
Signed-off-by: Ananth N Mavinakayanahalli
---
arch/powerpc/kernel/uprobes.c |6 --
1 file changed, 6 deletions(-)
From: Ananth N Mavinakayanahalli
Powerpc has many trap variants that could be used by entities like gdb.
Currently, running gdb on a program being traced by uprobes causes an
endless loop since uprobes doesn't understand that the trap was inserted
by some other entity and a SIGTRAP needs
From: Ananth N Mavinakayanahalli
Refuse to place a uprobe if a trap variant already exists in the
file copy at the address.
Signed-off-by: Ananth N Mavinakayanahalli
---
kernel/events/uprobes.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-3.9-rc3/kernel/events
From: Ananth N Mavinakayanahalli
Some architectures like powerpc have multiple variants of the trap
instruction. Introduce an additional helper is_trap_insn() for run-time
handling of non-uprobe traps on such architectures.
While there, change is_swbp_at_addr() to is_trap_at_addr() for reading
On Fri, Mar 22, 2013 at 03:54:06PM +0100, Oleg Nesterov wrote:
> On 03/22, Ananth N Mavinakayanahalli wrote:
> >
> > +/**
> > + * is_trap_insn - check if instruction is breakpoint instruction.
> > + * @insn: instruction to be checked.
> > + * Default implementatio
From: Ananth N Mavinakayanahalli
The current implementation of uprobes assumes that uprobes always wins
even when a register request is at a location with a conditional
breakpoint by some other entity. Refer to [1] for more details.
Remove the breakpoint instruction check during registration on
From: Ananth N Mavinakayanahalli
Powerpc has many trap variants that could be used by entities like gdb.
Currently, running gdb on a program being traced by uprobes causes an
endless loop since uprobes doesn't understand that the trap was inserted
by some other entity and a SIGTRAP needs
From: Ananth N Mavinakayanahalli
Some architectures like powerpc have multiple variants of the trap
instruction. Introduce an additional helper is_trap_insn() for run-time
handling of non-uprobe traps on such architectures.
While there, change is_swbp_at_addr() to is_trap_at_addr() for reading
On Thu, Mar 21, 2013 at 04:58:09PM +0100, Oleg Nesterov wrote:
> On 03/21, Ananth N Mavinakayanahalli wrote:
> >
> > On Wed, Mar 20, 2013 at 05:06:44PM +0100, Oleg Nesterov wrote:
> >
> > > > > But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, jus
On Thu, Mar 21, 2013 at 05:00:02PM +0100, Oleg Nesterov wrote:
> On 03/21, Ananth N Mavinakayanahalli wrote:
> ?
> > On Wed, Mar 20, 2013 at 05:07:28PM +0100, Oleg Nesterov wrote:
> > > On 03/20, Ananth N Mavinakayanahalli wrote:
> > > >
> > > > O
On Wed, Mar 20, 2013 at 05:07:28PM +0100, Oleg Nesterov wrote:
> On 03/20, Ananth N Mavinakayanahalli wrote:
> >
> > On Wed, Mar 20, 2013 at 01:43:01PM +0100, Oleg Nesterov wrote:
> > > On 03/20, Oleg Nesterov wrote:
> > > >
> > > > But we did not
On Wed, Mar 20, 2013 at 05:06:44PM +0100, Oleg Nesterov wrote:
> On 03/20, Ananth N Mavinakayanahalli wrote:
> >
> > On Wed, Mar 20, 2013 at 01:26:39PM +0100, Oleg Nesterov wrote:
> >
> > > But, at the same time, is the new definition fine for verify_opcode()?
> &
On Wed, Mar 20, 2013 at 01:43:01PM +0100, Oleg Nesterov wrote:
> On 03/20, Oleg Nesterov wrote:
> >
> > But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
> > verify. If not, we need 2 definitions. is_uprobe_insn() should still check
> > insns == UPROBE_SWBP_INSN, and is_swbp_
On Wed, Mar 20, 2013 at 01:26:39PM +0100, Oleg Nesterov wrote:
> Hi Ananth,
>
> First of all, let me remind that I know nothing about powerpc ;)
>
> But iirc we already discussed this a bit, I forgot the details but
> still I have some concerns...
>
> On 03/20, Ananth N
From: Ananth N Mavinakayanahalli
GDB uses a variant of the trap instruction that is different from the
one used by uprobes. Currently, running gdb on a program being traced
by uprobes causes an endless loop since uprobes doesn't understand
that the trap is inserted by some other entity and
;
> Signed-off-by: Suzuki K. Poulose
> Cc: Ananth N Mavinakaynahalli
> Cc: Kumar Gala
> Cc: linuxppc-...@ozlabs.org
Acked-by: Ananth N Mavinakayanahalli
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Sep 06, 2012 at 05:11:53PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc allyesconfig)
> failed like this:
>
> In file included from drivers/atm/fore200e.c:70:0:
> drivers/atm/fore200e.h:263:3: error: redefinition of typedef '
here
>
> This is a bit more annoying. Ananth, do we need that to be called
> opcode_t for generic reasons or can we make it ppc_opcode_t ? If it has
> to remain, I suppose we can try to change that ATM driver to use a
> different type name...
We can make it ppc_opcode_t. Attached
On Wed, Sep 05, 2012 at 03:26:59PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2012-08-24 at 13:01 +0530, Ananth N Mavinakayanahalli wrote:
> > From: Ananth N Mavinakayanahalli
> >
> > This is the port of uprobes to powerpc. Usage is similar to x86.
>
> Guys, ca
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 c
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
Add thread_struct.trap_nr and use it to store the last exception
the thread experienced. In this patch, we populate the field at
various places where we force_sig_info() to the process.
This is also used in uprobes to determine if the probed instruction
caused
From: Ananth N Mavinakayanahalli
Move is_trap() and relatives to a common file to be shared between *probes.
Code movement only; no change in functionality.
Suggested by Michael Ellerman.
Signed-off-by: Ananth N Mavinakayanahalli
---
arch/powerpc/include/asm/kprobes.h | 15
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,
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
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
Add thread_struct.trap_nr and use it to store the last exception
the thread experienced. In this patch, we populate the field at
various places where we force_sig_info() to the process.
This is also used in uprobes to determine if the probed instruction
caused
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
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.
>
> > o
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 po
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
Add thread_struct.trap_nr and use it to store the last exception
the thread experienced. In this patch, we populate the field at
various places where we force_sig_info() to the process.
This is also used in uprobes to determine if the probed instruction
caused
On Tue, Jun 12, 2012 at 02:01:46PM +1000, Michael Ellerman wrote:
> On Fri, 2012-06-08 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:
> > On Fri, Jun 08, 2012 at 04:38:17PM +1000, Michael Ellerman wrote:
> > > On Fri, 2012-06-08 at 11:49 +0530, Ananth N Mavinakayanahalli wro
From: Ananth N Mavinakayanahalli
This is the port of uprobes to powerpc. Usage is similar to x86.
One TODO in this port compared to x86 is the uprobe abort_xol() logic.
x86 depends on the thread_struct.trap_nr (absent in powerpc) to determine
if a signal was caused when the uprobed instruction
From: Ananth N Mavinakayanahalli
On RISC architectures like powerpc, instructions are fixed size.
Instruction analysis on such platforms is just a matter of (insn % 4).
Pass the vaddr at which the uprobe is to be inserted so that
arch_uprobe_analyze_insn() can flag misaligned registration
On Fri, Jun 08, 2012 at 04:38:17PM +1000, Michael Ellerman wrote:
> On Fri, 2012-06-08 at 11:49 +0530, Ananth N Mavinakayanahalli wrote:
> > On Fri, Jun 08, 2012 at 04:17:44PM +1000, Michael Ellerman wrote:
> > > On Fri, 2012-06-08 at 11:31 +0530, Ananth N Mavinakayanahalli wro
On Fri, Jun 08, 2012 at 04:17:44PM +1000, Michael Ellerman wrote:
> On Fri, 2012-06-08 at 11:31 +0530, Ananth N Mavinakayanahalli wrote:
> > On Fri, Jun 08, 2012 at 03:51:54PM +1000, Michael Ellerman wrote:
> > > On Fri, 2012-06-08 at 10:06 +0530, Ananth N Mavinakayanahalli wro
On Fri, Jun 08, 2012 at 03:51:54PM +1000, Michael Ellerman wrote:
> On Fri, 2012-06-08 at 10:06 +0530, Ananth N Mavinakayanahalli wrote:
> > On Wed, Jun 06, 2012 at 11:08:04AM -0700, Jim Keniston wrote:
> > > On Wed, 2012-06-06 at 15:05 +0530, Ananth N Mavinakayanahalli wrote:
&
On Wed, Jun 06, 2012 at 11:08:04AM -0700, Jim Keniston wrote:
> On Wed, 2012-06-06 at 15:05 +0530, Ananth N Mavinakayanahalli wrote:
> > On Wed, Jun 06, 2012 at 11:27:02AM +0200, Peter Zijlstra wrote:
> > > On Wed, 2012-06-06 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:
On Wed, Jun 06, 2012 at 05:14:23PM +0530, Srikar Dronamraju wrote:
> * Ingo Molnar [2012-06-06 11:40:15]:
>
> >
> > * Ananth N Mavinakayanahalli wrote:
> >
> > > On Wed, Jun 06, 2012 at 11:23:52AM +0200, Peter Zijlstra wrote:
> > > >
On Wed, Jun 06, 2012 at 11:40:15AM +0200, Ingo Molnar wrote:
>
> * Ananth N Mavinakayanahalli wrote:
>
> > On Wed, Jun 06, 2012 at 11:23:52AM +0200, Peter Zijlstra wrote:
> > > On Wed, 2012-06-06 at 14:49 +0530, Ananth N Mavinakayanahalli wrote:
> > > >
On Wed, Jun 06, 2012 at 11:23:52AM +0200, Peter Zijlstra wrote:
> On Wed, 2012-06-06 at 14:49 +0530, Ananth N Mavinakayanahalli wrote:
> > +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
> > *mm, loff_t vaddr)
>
> Don't we traditionally
On Wed, Jun 06, 2012 at 11:27:02AM +0200, Peter Zijlstra wrote:
> On Wed, 2012-06-06 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:
> > One TODO in this port compared to x86 is the uprobe abort_xol() logic.
> > x86 depends on the thread_struct.trap_nr (absent in powerpc) to det
From: Ananth N Mavinakayanahalli
This is the port of uprobes to powerpc. Usage is similar to x86.
One TODO in this port compared to x86 is the uprobe abort_xol() logic.
x86 depends on the thread_struct.trap_nr (absent in powerpc) to determine
if a signal was caused when the uprobed instruction
From: Ananth N Mavinakayanahalli
On RISC architectures like powerpc, instructions are fixed size.
Instruction analysis on such platforms is just a matter of (insn % 4).
Pass the vaddr at which the uprobe is to be inserted so that
arch_uprobe_analyze_insn() can flag misaligned registration
On Fri, Nov 11, 2011 at 10:17:55AM +0530, Ananth N Mavinakayanahalli wrote:
> >
> > At this rate we're going to end up with no bits left for CPU features
> > way too quickly... Especially for something we only care about once at
> > boot time.
> >
> >
On Fri, Nov 11, 2011 at 03:18:14PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2011-11-10 at 14:18 +0530, Ananth N Mavinakayanahalli wrote:
>
> >
> > From: Ananth N Mavinakayanahalli
> >
> > The Processor Identification Register (PIR) on some powerpc platfor
On Wed, Nov 09, 2011 at 09:48:25AM -0600, Scott Wood wrote:
> On Wed, Nov 09, 2011 at 10:11:24AM +0530, Ananth N Mavinakayanahalli wrote:
> > On Tue, Nov 08, 2011 at 10:59:46AM -0600, Scott Wood wrote:
> > > On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > >
On Tue, Nov 08, 2011 at 10:59:46AM -0600, Scott Wood wrote:
> On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> >> What use does userspace have for this? If you want to return the
> >> currently
On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> On 11/06/2011 10:47 PM, Ananth N Mavinakayanahalli wrote:
> > The Processor Identification Register (PIR) on powerpc provides
> > information to decode the processor identification tag. Decoding
> > this informa
supported powerpc platforms that
don't have it. Code in the kernel referencing PIR isn't under
a platform ifdef).
Signed-off-by: Ananth N Mavinakayanahalli
---
arch/powerpc/kernel/sysfs.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-3.1/arch/po
On Mon, Jul 11, 2011 at 10:39:35AM +0800, Tiejun Chen wrote:
> When enable CONFIG_PREEMPT we will trigger the following call trace:
>
> BUG: scheduling while atomic: swapper/1/0x1000
> ...
>
> krpobe always goes through the following path:
>
> program_check_exception()
> |
>
On Wed, Jun 29, 2011 at 02:23:28PM +0800, Yong Zhang wrote:
> On Mon, Jun 27, 2011 at 6:01 PM, Ananth N Mavinakayanahalli
> wrote:
> > On Sun, Jun 26, 2011 at 11:47:13PM +0900, Masami Hiramatsu wrote:
> >> (2011/06/24 19:29), Steven Rostedt wrote:
> >> > On Fri
On Mon, Jun 27, 2011 at 03:31:05PM +0530, Ananth N Mavinakayanahalli wrote:
> On Sun, Jun 26, 2011 at 11:47:13PM +0900, Masami Hiramatsu wrote:
> > (2011/06/24 19:29), Steven Rostedt wrote:
> > > On Fri, 2011-06-24 at 17:21 +0800, Yong Zhang wrote:
> > >> Hi,
> &g
On Sun, Jun 26, 2011 at 11:47:13PM +0900, Masami Hiramatsu wrote:
> (2011/06/24 19:29), Steven Rostedt wrote:
> > On Fri, 2011-06-24 at 17:21 +0800, Yong Zhang wrote:
> >> Hi,
> >>
> >> When I use kprobe to do something, I found some wired thing.
> >>
> >> When CONFIG_FUNCTION_TRACER is disabled:
>
1203.ga20...@in.ibm.com> you wrote:
> > > > Hi Paul,
> > > >
> > > > While we are at it, can we also add nop to the list of emulated
> > > > instructions?
> > > >
> > > > Ananth
> > > > ---
> > > > From:
On Fri, May 28, 2010 at 12:05:56PM +1000, Paul Mackerras wrote:
> On Thu, May 27, 2010 at 07:42:03PM +0530, Ananth N Mavinakayanahalli wrote:
>
> > While we are at it, can we also add nop to the list of emulated
> > instructions?
>
> I have a patch in development t
On Fri, May 28, 2010 at 12:28:43PM +1000, Michael Neuling wrote:
>
>
> In message <20100527141203.ga20...@in.ibm.com> you wrote:
> > Hi Paul,
> >
> > While we are at it, can we also add nop to the list of emulated
> > instructions?
> >
> >
1 - 100 of 108 matches
Mail list logo
