Re: [PATCH 2/2] [POWERPC] uprobes: powerpc port

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:

quoted

On Fri, 2012-06-08 at 10:06 +0530, Ananth N Mavinakayanahalli wrote:

quoted

On Wed, Jun 06, 2012 at 11:08:04AM -0700, Jim Keniston wrote:

quoted

On Wed, 2012-06-06 at 15:05 +0530, Ananth N Mavinakayanahalli wrote:

quoted

On Wed, Jun 06, 2012 at 11:27:02AM +0200, Peter Zijlstra wrote:

quoted

On Wed, 2012-06-06 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:

...

quoted

quoted

For the kernel, the only ones that are off limits are rfi (return from
interrupt), mtmsr (move to msr). All other instructions can be probed.

Both those instructions are supervisor level, so we won't see them in
userspace at all; so we should be able to probe all user level
instructions.

Presumably rfi or mtmsr could show up in the instruction stream via an
erroneous or mischievous asm statement.  It'd be good to verify that you
handle that gracefully.

That'd be flagged elsewhere, by the architecture itself -- you'd get a
privileged instruciton exception if you try execute any instruction not
part of the UISA. I therefore don't think its a necessary check in the
uprobes code.

But you're not executing the instruction, you're passing it to
emulate_step(). Or am I missing something?

But MSR_PR=1 and hence emulate_step() will return -1 and hence we will
end up single-stepping using user_enable_single_step(). Same with rfid.

Right. But that was exactly Jim's point, you may be asked to emulate
those instructions even though you wouldn't expect to see them in
userspace code, so you need to handle it.

Luckily it looks like emulate_step() will do the right thing for you.
It'd be good to test it to make 100% sure.

cheers