| To: | ananth@xxxxxxxxxx |
|---|---|
| Subject: | Re: Race in kdb() |
| From: | Keith Owens <kaos@xxxxxxx> |
| Date: | Tue, 20 Apr 2004 13:09:16 +1000 |
| Cc: | kdb@xxxxxxxxxxx |
| In-reply-to: | Your message of "Mon, 19 Apr 2004 19:50:08 +0500." <20040419145008.GA13342@xxxxxxxxxx> |
| Sender: | kdb-bounce@xxxxxxxxxxx |
On Mon, 19 Apr 2004 19:50:08 +0500,
Ananth N Mavinakayanahalli <ananth@xxxxxxxxxx> wrote:
>Hi,
>
>While working on KDB for ppc64, I hit a race in kdb(). Verified that the
>problem exists on x86 too..
>
>Problem occurs when a bp is set on a very frequently hit routine (eg.,
>sys_read() or schedule()), and multiple processors hit the bp
>simultaneously. This is the problem I am seeing...
>
> CPU0 CPU1
> | |
> kdb(reason = break) |
> | |
> | |
> spin_lock() |
> | |
> kdb_initial_cpu = 0; |
> | |
> spin_unlock() |
> .. kdb(reason = break)
> | |
> | if (reason != KDB_REASON_SWITCH) {
> | if (KDB_IS_RUNNING() && !KDB_STATE(REENTRY))
> | <is true>
> | ....
> |
> |
> smp_kdb_stop();
I know. Fixing this trace requires significant changes to the way that
breakpoints are handled and will break kdb for all architectures. It
is on my list for kdb v5.0.
---------------------------
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Race in kdb(), Xavier Bru |
|---|---|
| Next by Date: | Two questions about KDB portability, Marco Caverzaghi |
| Previous by Thread: | Re: Race in kdb(), Xavier Bru |
| Next by Thread: | Two questions about KDB portability, Marco Caverzaghi |
| Indexes: | [Date] [Thread] [Top] [All Lists] |