[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] Fix locking bug in vcpu_migrate
- To: John Weekes <lists.xen@xxxxxxxxxxxxxxxxxx>
- From: Keir Fraser <keir.xen@xxxxxxxxx>
- Date: Fri, 22 Apr 2011 19:43:24 +0100
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>
- Delivery-date: Fri, 22 Apr 2011 11:44:16 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=hi8rqSIvZ+CL6rRoT1xe4bU7zqPGk/vLci24UXJuDOY=; b=mAiEqZhgSrFuFdJeXQfwQTUofgiMywkL28JCGU52Kt9H+lB/NnDmX9AXyrlT9ISbqc u/MzgLVOAMnBRUxBnzJsNEoeJHWjJ7xaBfZ3x+D/b7g5buzbvM19Ml2dqY6beqcUPDwU 2yBICWSQtni4V5aztwYa9k1MmwKvYbGxGUGFw=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=rVOGOKUTOfSAJuCoRXpv5Bb687Qb40hbedXkhcsyP+C/f0fDoK9TnsiwY++8i/n595 MA8z/E13GspUjg7Z9fSJIz3XpX10733HjE98xvaPasqsWCr0NS+3tq1xcY5Q3GYnZPVx IgC7dl9uE54DOXHHpUqUprWweR8E6fXRtTk3Y=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- Thread-index: AcwBHSj5PgzvIyXiCU2ywYSoztP6Ng==
- Thread-topic: [Xen-devel] [PATCH] Fix locking bug in vcpu_migrate
On 22/04/2011 19:23, "John Weekes" <lists.xen@xxxxxxxxxxxxxxxxxx> wrote:
>
>> Nice that empirical evidence supports the patch, however, I'm being dense
>> and don't understand why order of lock release matters.
>
> I was taught long ago to release them in order, but as I think about it,
> I agree with you that there doesn't seem to be a scenario when the
> release would matter.
>
> It's odd that it seemed to lead to such a big difference for me, then.
> I'll do some further tests -- maybe I changed something else to cause
> the behavior, or the problem is more random than I thought and just
> hasn't occurred for me yet in all the new tests.
Thanks!
-- Keir
>> perhaps you've merely perturbed a fragile pos code that's
>> broken in some other way.
>
> That's entirely possible.
>
>> Also the last hunk of your patch is broken -- in the final else clause you
>> call spin_unlock_irqrestore on the wrong lock. This is very definitely a
>> bug, as irqs should never be enabled while any schedule_lock is held.
>
> Definitely. I had fixed that here but sent an old version of the patch
> -- a boneheaded mistake.
>
> -John
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel