Re: [PATCH 35 of 36] x86: make pgd/pud/pmd/pte_none consistent

[Ian Campbell]

On Fri, 2009-02-06 at 15:45 +0000, Ian Campbell wrote:
> On Fri, 2009-02-06 at 15:29 +0000, Ian Campbell wrote:
> > On Thu, 2009-02-05 at 11:31 -0800, Jeremy Fitzhardinge wrote:
> > > The _none test is done differently for every level of the pagetable.
> > > Standardize them by:
> > > 
> > >  1: Use the native_X_val to extract the raw entry, with no need to go
> > >     via paravirt_ops, diff -r 1d0646d0d319 arch/x86/include/asm/pgtable.h, and
> > >  2: Compare with 0 rather than using a boolean !, since they are actually values
> > >     and not booleans.
> > 
> > In a 32 bit Xen guest this one causes
> > 
> >         [    8.354898] 1 multicall(s) failed: cpu 1
> 
> Spoke too soon, it's not as 100% reliably reproducing as I thought which
> confused my bisection attempt. Will try and locate the real culprit...

Real culprit was somewhere else entirely:

Subject: Fix xen_flush_tlb_others after const cpumask changes 

The commit
    commit 4595f9620cda8a1e973588e743cf5f8436dd20c6
    Author: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
    Date:   Sat Jan 10 21:58:09 2009 -0800

        x86: change flush_tlb_others to take a const struct cpumask

causes xen_flush_tlb_others to allocate a multicall and then issue it
without initializing it in the case where the cpumask is empty,
leading to:

        [    8.354898] 1 multicall(s) failed: cpu 1
        [    8.354921] Pid: 2213, comm: bootclean Not tainted 2.6.29-rc3-x86_32p-xenU-tip #135
        [    8.354937] Call Trace:
        [    8.354955]  [<c01036e3>] xen_mc_flush+0x133/0x1b0
        [    8.354971]  [<c0105d2a>] ? xen_force_evtchn_callback+0x1a/0x30
        [    8.354988]  [<c0105a60>] xen_flush_tlb_others+0xb0/0xd0
        [    8.355003]  [<c0126643>] flush_tlb_page+0x53/0xa0
        [    8.355018]  [<c0176a80>] do_wp_page+0x2a0/0x7c0
        [    8.355034]  [<c0238f0a>] ? notify_remote_via_irq+0x3a/0x70
        [    8.355049]  [<c0178950>] handle_mm_fault+0x7b0/0xa50
        [    8.355065]  [<c0131a3e>] ? wake_up_new_task+0x8e/0xb0
        [    8.355079]  [<c01337b5>] ? do_fork+0xe5/0x320
        [    8.355095]  [<c0121919>] do_page_fault+0xe9/0x240
        [    8.355109]  [<c0121830>] ? do_page_fault+0x0/0x240
        [    8.355125]  [<c032457a>] error_code+0x72/0x78
        [    8.355139]   call  1/1: op=2863311530 arg=[aaaaaaaa] result=-38     xen_flush_tlb_others+0x41/0xd0

Since empty cpumasks are rare and undoing an xen_mc_entry() is tricky
just issue such requests normally.

Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxx>
Cc: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Cc: Mike Travis <travis@xxxxxxx>
Cc: x86@xxxxxxxxxx
---
 arch/x86/xen/mmu.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d2e8ed1..319bd40 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1273,8 +1273,6 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
 	/* Remove us, and any offline CPUS. */
 	cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
 	cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));
-	if (unlikely(cpumask_empty(to_cpumask(args->mask))))
-		goto issue;
 
 	if (va == TLB_FLUSH_ALL) {
 		args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
@@ -1285,7 +1283,6 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
 
 	MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);
 
-issue:
 	xen_mc_issue(PARAVIRT_LAZY_MMU);
 }
 
-- 
1.5.6.5


-- 
Ian Campbell

We are now enjoying total mutual interaction in an imaginary hot tub ...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/