This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] next->vcpu_dirty_cpumask checking at the top of context_swit

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] next->vcpu_dirty_cpumask checking at the top of context_switch()
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 16 Apr 2009 16:16:37 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 16 Apr 2009 08:15:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
In an attempt to create a patch to remove some of the cpumask copying
(in order to reduce stack usage when NR_CPUS is huge) one of the obvious
things to do was to change function parameters to pointer-to-cpumask.
However, doing so for flush_area_mask() creates the unintended side
effect of triggering the WARN_ON() at the top of send_IPI_mask_flat(),
apparently because next->vcpu_dirty_cpumask can occasionally change
between the call site of flush_tlb_mask() in context_switch() and that low
level routine.

That by itself certainly is not a problem, what puzzles me are the redundant
!cpus_empty() checks prior to the call to flush_tlb_mask() as well as the
fact that if I'm hitting a possible timing window here, then I can't see why
it shouldn't be possible to hit the (albeit much smaller) window between the
second !cpus_empty() check and the point where the cpumask got fully
copied to the stack as flush_tlb_mask()'s argument.

Bottom line question is - can't the second !cpus_empty() check go away
altogether, and shouldn't the argument passed to flush_tlb_mask() be
dirty_mask instead of next->vcpu_dirty_cpumask?

Thanks for any insights,

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>