linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: "Huang, Yuanjie" <yuanjie.huang@windriver.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	<linuxppc-dev@lists.ozlabs.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>
Subject: Re: powerpc/fsl_book3e: fix the relocatable bug in debug interrupt handler
Date: Mon, 10 Aug 2015 13:57:49 -0500	[thread overview]
Message-ID: <1439233069.2097.227.camel@freescale.com> (raw)
In-Reply-To: <55C80B29.7050308@windriver.com>

On Mon, 2015-08-10 at 10:23 +0800, Huang, Yuanjie wrote:
> Hi Scott,
> 
> On 08/08/2015 10:29 AM, Scott Wood wrote:
> > [Please wrap commit messages at around 74 columns]
> Ok, I will when sending a new version.
> > 
> > On Fri, Aug 07, 2015 at 02:58:10PM +0800, Yuanjie Huang wrote:
> > > PowerPC Book3E processor features hardware-supported single instruction
> > > execution, and it is used for ptrace(PTRACE_SINGLESTEP, ...).  When a
> > > debugger loads a debuggee, it typically sets the CPU to yield debug
> > > interrupt on first instruction complete or branch taken.  However, the
> > > newly-forked child process could run into instruction TLB miss
> > > exception handler when switched to, and causes a debug interrupt in the
> > > exception entry sequence.  This is not expected by caller of
> > > ptrace(PTRACE_SINGLESTEP, ...), so the next instruction address saved
> > > in DSRR0 is checked against the boundary of exception entry sequence,
> > > to ensure the kernel only process the interrupt as a normal exception
> > > if the address does not fall in the exception entry sequence.  Failure
> > > in obtaining the correct boundary leads to such debug exception handled
> > > as from privileged mode, and causes kernel oops.
> > > 
> > > The LOAD_REG_IMMEDIATE can't be used to load the boundary addresses
> > > when relocatable enabled, so this patch replace them with
> > > LOAD_REG_ADDR_PIC.  LR is backed up and restored before and after
> > > calling LOAD_REG_ADDR_PIC, because LOAD_REG_ADDR_PIC clobbers it.
> > > 
> > > Signed-off-by: Yuanjie Huang <Yuanjie.Huang@windriver.com>
> > > ---
> > >   arch/powerpc/kernel/exceptions-64e.S | 24 ++++++++++++++++++++++++
> > >   1 file changed, 24 insertions(+)
> > > 
> > > diff --git a/arch/powerpc/kernel/exceptions-64e.S 
> > > b/arch/powerpc/kernel/exceptions-64e.S
> > > index 3e68d1c..c475f569 100644
> > > --- a/arch/powerpc/kernel/exceptions-64e.S
> > > +++ b/arch/powerpc/kernel/exceptions-64e.S
> > > @@ -735,12 +735,24 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> > >           andis.  r15,r14,(DBSR_IC|DBSR_BT)@h
> > >           beq+    1f
> > >   
> > > +#ifdef CONFIG_RELOCATABLE
> > > + mflr    r14
> > > + LOAD_REG_ADDR_PIC(r15,interrupt_base_book3e)
> > > + mtlr    r14
> > > + cmpld   cr0,r10,r15
> > > + blt+    cr0,1f
> > > + LOAD_REG_ADDR_PIC(r15,interrupt_end_book3e)
> > > + mtlr    r14
> > > + cmpld   cr0,r10,r15
> > > + bge+    cr0,1f
> > > +#else
> > CONFIG_RELOCATABLE is not supported on 64-bit book3e without applying
> > additional patches, such as the RFC patchset I posted recently that
> > contained the patch "powerpc/book3e-64: rename interrupt_end_book3e with
> > __end_interrupts".  But if you've applied that patchset, then you
> > wouldn't be working with the name interrupt_base_book3e, so how are you
> > seeing this?
> 
> Actually I have merged additional patches submitted but not merged to 
> make CONFIG_RELOCATABLE work with 64-bit book3e. I am happy to delay 
> this until those patches are merged, and sent an adjusted version. Shall 
> I wait until they are merged?

Yes, or base the patch on top of them and cite the dependency below the --- 
line in the changelog.

-Scott
> 

      reply	other threads:[~2015-08-10 18:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07  6:58 [PATCH] powerpc/fsl_book3e: fix the relocatable bug in debug interrupt handler Yuanjie Huang
2015-08-08  2:29 ` Scott Wood
2015-08-10  2:23   ` Huang, Yuanjie
2015-08-10 18:57     ` Scott Wood [this message]

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=1439233069.2097.227.camel@freescale.com \
    --to=scottwood@freescale.com \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paul.gortmaker@windriver.com \
    --cc=paulus@samba.org \
    --cc=yuanjie.huang@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).