From: Scott Wood <scottwood@freescale•com>
To: Tiejun Chen <tiejun.chen@windriver•com>
Cc: linuxppc-dev@lists•ozlabs.org, linux-kernel@vger•kernel.org
Subject: Re: [v6][PATCH 5/5] powerpc/book3e/kgdb: Fix a single stgep case of lazy IRQ
Date: Tue, 17 Dec 2013 20:45:13 -0600 [thread overview]
Message-ID: <1387334713.3140.8.camel@snotra.buserror.net> (raw)
In-Reply-To: <1382520685-11609-6-git-send-email-tiejun.chen@windriver.com>
On Wed, 2013-10-23 at 17:31 +0800, Tiejun Chen wrote:
> In lazy EE magic, we may have a lazy interrupt occured while
> entering kgdb, but we really don't want to replay that interrupt
> for kgdb, so we have to clear the PACA_IRQ_HARD_DIS force to
> make sure we can exit directly from this debug exception.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver•com>
s/stgep/step/ in subject
> ---
> arch/powerpc/kernel/kgdb.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 447c14b..9872f58 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -185,6 +185,14 @@ static int kgdb_singlestep(struct pt_regs *regs)
> /* Restore current_thread_info lastly. */
> memcpy(exception_thread_info, backup_current_thread_info, sizeof *thread_info);
>
> +#ifdef CONFIG_PPC64
> + /*
> + * Clear the PACA_IRQ_HARD_DIS from the pending mask
> + * since we are about to exit this directly from debug
> + * exception without any replay interrupt in lazy EE case.
> + */
> + local_paca->irq_happened &= ~PACA_IRQ_HARD_DIS;
> +#endif
> return 1;
> }
>
What happens to those interrupts you discarded once we get back to a
state when they can be safely replayed? I don't think just dropping
them is the answer.
I'm not sure what the actual problem is. I can understand not wanting
kgdb to cause interrupts to appear to run when the interrupted context
has external interrupts disabled, but the replay code in entry_64.S
doesn't run if interrupts are soft-disabled in the context to be
returned to. What harm does it cause to run the interrupts if we're
returning to an EE=1 context?
Does KGDB enable interrupts in its handler? If not, how do we even get
into the situation where there are interrupts pending when the
interrupted context has EE soft-enabled (i.e. we went directly from a
context where the interrupt handler should have run, to a hard-disabled
context)?
-Scott
next prev parent reply other threads:[~2013-12-18 2:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-23 9:31 [v6][PATCH 0/5] powerpc/book3e: powerpc/book3e: make kgdb to work well Tiejun Chen
2013-10-23 9:31 ` [v6][PATCH 1/5] powerpc/book3e: initialize crit/mc/dbg kernel stack pointers Tiejun Chen
2013-10-23 9:31 ` [v6][PATCH 2/5] powerpc/book3e: store crit/mc/dbg exception thread info Tiejun Chen
2013-12-18 2:45 ` Scott Wood
2014-01-15 1:27 ` [v6,2/5] " Scott Wood
2013-10-23 9:31 ` [v6][PATCH 3/5] powerpc/book3e: support kgdb for kernel space Tiejun Chen
2014-05-09 19:36 ` [v6,3/5] " Scott Wood
2013-10-23 9:31 ` [v6][PATCH 4/5] powerpc/kgdb: use DEFINE_PER_CPU to allocate kgdb's thread_info Tiejun Chen
2013-10-23 9:31 ` [v6][PATCH 5/5] powerpc/book3e/kgdb: Fix a single stgep case of lazy IRQ Tiejun Chen
2013-12-18 2:45 ` Scott Wood [this message]
2013-11-18 8:36 ` [v6][PATCH 0/5] powerpc/book3e: powerpc/book3e: make kgdb to work well "“tiejun.chen”"
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=1387334713.3140.8.camel@snotra.buserror.net \
--to=scottwood@freescale$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=tiejun.chen@windriver$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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