Date: Sat, 9 Apr 2005 15:58:10 -0700
From: "David S. Miller" <davem@davemloft.net>
To: davidm@hpl.hp.com
Cc: davidm@napali.hpl.hp.com, mingo@elte.hu, tony.luck@intel.com,
       linux-kernel@vger.kernel.org
Subject: Re: [patch] sched: unlocked context-switches
Message-Id: <20050409155810.593d8f7b.davem@davemloft.net>
In-Reply-To: <16983.33049.962002.335198@napali.hpl.hp.com>
References: <3R6Ir-89Y-23@gated-at.bofh.it>
	<ugoecowjci.fsf@panda.mostang.com>
	<20050409070738.GA5444@elte.hu>
	<16983.33049.962002.335198@napali.hpl.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 900
Lines: 20

On Sat, 9 Apr 2005 00:15:37 -0700
David Mosberger <davidm@napali.hpl.hp.com> wrote:

> Yes, of course.  The deadlock was due to context-switching, not
> switch_mm() per se.  Hopefully someone else beats me to remembering
> the details before Monday.

Sparc64 has a deadlock because we hold mm->page_table_lock during
switch_mm().  I bet IA64 did something similar, as I remember it
had a very similar locking issue in this area.

So the deadlock was, we held the runqueue locks over switch_mm(),
switch_mm() spins on mm->page_table_lock, the cpu which does have
mm->page_table_lock tries to do a wakeup on the first cpu's runqueue.
Classic AB-BA deadlock.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/