All of lore.kernel.org
 help / color / mirror / Atom feed
From: "\"“tiejun.chen”\"" <tiejun.chen@windriver.com>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [v5][PATCH 6/6] book3e/kgdb: Fix a single stgep case of lazy IRQ
Date: Wed, 23 Oct 2013 17:28:12 +0800	[thread overview]
Message-ID: <526796AC.9000207@windriver.com> (raw)
In-Reply-To: <1382139147.7979.934.camel@snotra.buserror.net>

On 10/19/2013 07:32 AM, Scott Wood wrote:
> On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
>> When we're in kgdb_singlestep(), we have to work around to get
>> thread_info by copying from the kernel stack before calling
>> kgdb_handle_exception(), then copying it back afterwards.
>>
>> But for PPC64, we have a lazy interrupt implementation. So after
>> copying thread info frome kernle stack, if we need to replay an
>> interrupt, we shouldn't restore that previous backup thread info
>> to make sure we can replay an interrupt lately with a proper
>> thread info.
>
> Explain why copying it would be a problem.
>

This would be gone away in next version as well :)

Thanks,

Tiejun

WARNING: multiple messages have this Message-ID (diff)
From: "\"“tiejun.chen”\"" <tiejun.chen@windriver.com>
To: Scott Wood <scottwood@freescale.com>
Cc: <benh@kernel.crashing.org>, <linuxppc-dev@lists.ozlabs.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [v5][PATCH 6/6] book3e/kgdb: Fix a single stgep case of lazy IRQ
Date: Wed, 23 Oct 2013 17:28:12 +0800	[thread overview]
Message-ID: <526796AC.9000207@windriver.com> (raw)
In-Reply-To: <1382139147.7979.934.camel@snotra.buserror.net>

On 10/19/2013 07:32 AM, Scott Wood wrote:
> On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
>> When we're in kgdb_singlestep(), we have to work around to get
>> thread_info by copying from the kernel stack before calling
>> kgdb_handle_exception(), then copying it back afterwards.
>>
>> But for PPC64, we have a lazy interrupt implementation. So after
>> copying thread info frome kernle stack, if we need to replay an
>> interrupt, we shouldn't restore that previous backup thread info
>> to make sure we can replay an interrupt lately with a proper
>> thread info.
>
> Explain why copying it would be a problem.
>

This would be gone away in next version as well :)

Thanks,

Tiejun


  reply	other threads:[~2013-10-23  9:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-20 10:28 [v5][PATCH 0/6] powerpc/book3e: powerpc/book3e: make kgdb to work well Tiejun Chen
2013-06-20 10:28 ` Tiejun Chen
2013-06-20 10:28 ` [v5][PATCH 1/6] powerpc/book3e: load critical/machine/debug exception stack Tiejun Chen
2013-06-20 10:28   ` Tiejun Chen
2013-10-18 22:37   ` Scott Wood
2013-10-18 22:37     ` Scott Wood
2013-10-23  9:26     ` "“tiejun.chen”"
2013-10-23  9:26       ` "“tiejun.chen”"
2013-10-18 23:55   ` Scott Wood
2013-10-18 23:55     ` Scott Wood
2013-10-23  9:28     ` "“tiejun.chen”"
2013-10-23  9:28       ` "“tiejun.chen”"
2013-06-20 10:28 ` [v5][PATCH 2/6] powerpc/book3e: store critical/machine/debug exception thread info Tiejun Chen
2013-06-20 10:28   ` Tiejun Chen
2013-10-18 22:43   ` Scott Wood
2013-10-18 22:43     ` Scott Wood
2013-10-23  9:27     ` "“tiejun.chen”"
2013-10-23  9:27       ` "“tiejun.chen”"
2013-06-20 10:28 ` [v5][PATCH 3/6] book3e/kgdb: update thread's dbcr0 Tiejun Chen
2013-06-20 10:28   ` Tiejun Chen
2013-10-18 22:57   ` Scott Wood
2013-10-18 22:57     ` Scott Wood
2013-10-23  9:27     ` "“tiejun.chen”"
2013-10-23  9:27       ` "“tiejun.chen”"
2013-06-20 10:28 ` [v5][PATCH 4/6] powerpc/book3e: support kgdb for kernel space Tiejun Chen
2013-06-20 10:28   ` Tiejun Chen
2013-10-18 22:58   ` Scott Wood
2013-10-18 22:58     ` Scott Wood
2013-10-23  9:27     ` "“tiejun.chen”"
2013-10-23  9:27       ` "“tiejun.chen”"
2013-06-20 10:28 ` [v5][PATCH 5/6] powerpc/kgdb: use DEFINE_PER_CPU to allocate kgdb's thread_info Tiejun Chen
2013-06-20 10:28   ` Tiejun Chen
2013-06-20 10:28 ` [v5][PATCH 6/6] book3e/kgdb: Fix a single stgep case of lazy IRQ Tiejun Chen
2013-06-20 10:28   ` Tiejun Chen
2013-10-18 23:32   ` Scott Wood
2013-10-18 23:32     ` Scott Wood
2013-10-23  9:28     ` "“tiejun.chen”" [this message]
2013-10-23  9:28       ` "“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=526796AC.9000207@windriver.com \
    --to=tiejun.chen@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=scottwood@freescale.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.