linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Tiejun Chen <tiejun.chen@windriver.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v2 2/3] ppc32/kprobe: complete kprobe and migrate exception frame
Date: Thu, 10 May 2012 13:50:05 +1000	[thread overview]
Message-ID: <1336621805.3881.38.camel@pasglop> (raw)
In-Reply-To: <1323946810-4868-3-git-send-email-tiejun.chen@windriver.com>

On Thu, 2011-12-15 at 19:00 +0800, Tiejun Chen wrote:
> We can't emulate stwu since that may corrupt current exception stack.
> So we will have to do real store operation in the exception return code.
> 
> Firstly we'll allocate a trampoline exception frame below the kprobed
> function stack and copy the current exception frame to the trampoline.
> Then we can do this real store operation to implement 'stwu', and reroute
> the trampoline frame to r1 to complete this exception migration.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
> ---
>  arch/powerpc/kernel/entry_32.S |   35 +++++++++++++++++++++++++++++++++++
>  1 files changed, 35 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 56212bc..0cdd27d 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -850,6 +850,41 @@ resume_kernel:
>  
>  	/* interrupts are hard-disabled at this point */
>  restore:
> +	lwz	r3,_MSR(r1)	/* Returning to user mode? */
> +	andi.	r0,r3,MSR_PR
> +	bne	1f	

 .../...

Wouldn't it be better to use resume_kernel here ?

IE. We already have restore_user vs. resume_kernel labels, including
the PR test. In the !PREEMPT case, resume_kernel is empty but it's
there, so you can just "populate" it, ie, something like:

restore_user:
	... existing dbcr0 stuff ...
	b restore

resume_kernel: <-- removed the ifdef CONFIG_PREEMPT

	... Do the stack store business here...

#ifdef CONFIG_PREEMPT
	... move the preempt code here...
#endif

restore:
	... existing stuff ...

Also, the added advantage is that the code to calc
the thread info pointer and load the TI_FLAG can be
shared now between your stuff and preempt, ie:

resume_kernel:
	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
	lwz	r0,TI_FLAGS(r9)
	andis.	r0,r0,_TIF_EMULATE_STACK_STORE@h
	bne-	emulate_stack_store
#ifdef CONFIG_PREEMPT
	lwz	r8,TI_PREEMPT(r9) <-- note use of r8 instead of r0,
                                      I -think- r8 can be clobbered
                                      here but pls dbl check
	cmpwi	0,r8,0
	bne	restore
	andi.	r0,r0,_TIF_NEED_RESCHED
	etc...
 	
> +	/* check current_thread_info, _TIF_EMULATE_STACK_STORE */
> +	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
> +	lwz	r0,TI_FLAGS(r9)
> +	andis.	r0,r0,_TIF_EMULATE_STACK_STORE@h
> +	beq+	1f	
> +
> +	addi	r9,r1,INT_FRAME_SIZE	/* Get the kprobed function entry */
> +
> +	lwz	r3,GPR1(r1)
> +	subi	r3,r3,INT_FRAME_SIZE	/* dst: Allocate a trampoline exception frame */
> +	mr	r4,r1			/* src:  current exception frame */
> +	li	r5,INT_FRAME_SIZE	/* size: INT_FRAME_SIZE */
> +	mr	r1,r3			/* Reroute the trampoline frame to r1 */
> +	bl	memcpy			/* Copy from the original to the trampoline */
> +
> +	/* Do real store operation to complete stwu */
> +	lwz	r5,GPR1(r1)
> +	stw	r9,0(r5)

Ok, I think I -finally- understand your trick of using r1 +
INT_FRAME_SIZE as the value to store :-) It makes sense and it's
actually a nice hack :-)

I would recommend that in the C code part of the emulation, you
add some sanity checking to make sure we don't overflow the
kernel stack etc... it should come in generally handy especially
if what's your trying to debug with kprobes is a kernel stack
overflow :-)

> +	/* Clear _TIF_EMULATE_STACK_STORE flag */
> +	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
> +	lis	r11,_TIF_EMULATE_STACK_STORE@h
> +	addi	r9,r9,TI_FLAGS
> +0:	lwarx	r8,0,r9
> +	andc	r8,r8,r11
> +#ifdef CONFIG_IBM405_ERR77
> +	dcbt	0,r9
> +#endif
> +	stwcx.	r8,0,r9
> +	bne-	0b
> +1:
> +
>  #ifdef CONFIG_44x
>  BEGIN_MMU_FTR_SECTION
>  	b	1f

BTW. Are you going to do a ppc64 variant of that patch ?

Cheers,
Ben.

  reply	other threads:[~2012-05-10  3:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-15 11:00 [PATCH v2 0/3] ppc32/kprobe: Fix a bug for kprobe stwu r1 Tiejun Chen
2011-12-15 11:00 ` [PATCH v2 1/3] powerpc/kprobe: introduce a new thread flag Tiejun Chen
2011-12-15 11:00 ` [PATCH v2 2/3] ppc32/kprobe: complete kprobe and migrate exception frame Tiejun Chen
2012-05-10  3:50   ` Benjamin Herrenschmidt [this message]
2012-06-03  5:01     ` tiejun.chen
2011-12-15 11:00 ` [PATCH v2 3/3] ppc32/kprobe: don't emulate store when kprobe stwu r1 Tiejun Chen
2012-01-10  9:15 ` [PATCH v2 0/3] ppc32/kprobe: Fix a bug for " tiejun.chen
2012-01-11  0:53   ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1336621805.3881.38.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=tiejun.chen@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).