Re: Question about x86/mm/gup.c's use of disabled interrupts

From: Jeremy Fitzhardinge
Date: Wed Mar 18 2009 - 17:23:55 EST


Avi Kivity wrote:
Jeremy Fitzhardinge wrote:
Disabling the interrupt will prevent the tlb flush IPI from coming in and flushing this cpu's tlb, but I don't see how it will prevent some other cpu from actually updating the pte in the pagetable, which is what we're concerned about here.

The thread that cleared the pte holds the pte lock and is now waiting for the IPI. The thread that wants to update the pte will wait for the pte lock, thus also waits on the IPI and gup_fast()'s local_irq_enable(). I think.

But hasn't it already done the pte update at that point?

(I think this conversation really is moot because the kernel never does P->P pte updates any more; its always P->N->P.)

Is this the only reason to disable interrupts?

Another comment says it also prevents pagetable teardown.

We could take a reference to the mm to get the same effect, no?

Also, assuming that disabling the interrupt is enough to get the guarantees we need here, there's a Xen problem because we don't use IPIs for cross-cpu tlb flushes (well, it happens within Xen). I'll have to think a bit about how to deal with that, but I'm thinking that we could add a per-cpu "tlb flushes blocked" flag, and maintain some kind of per-cpu deferred tlb flush count so we can get around to doing the flush eventually.

I was thinking about adding a hypercall for cross-vcpu tlb flushes. Guess I'll wait for you to clear up all the issues first.

Typical...

J

--
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/