Re: 2.6.32 PV Xen donU guest panic on nested call to arch_enter_lazy_mmu_mode()

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 12/08/2010 05:21 PM, Chuck Anderson wrote:
> Jeremy,
>  Is it possible for an ongoing lazy mode update to have batched some
> MMU updates; an interrupt occurs; an interrupt routine does a non-lazy
> MMU update for a PTE that is also in the lazy update queue; that
> update is overwritten on return from the interrupt when the update
> queue is flushed?  Or are the PTE updates protected by a lock?  If
> they are, wouldn't we deadlock in the interrupt routine when it tries
> to obtain that (I assume) spinlock?

The kernel-wide rule is that to update a usermode pte, you must be
holding the appropriate pte lock.  The pte lock is not interrupt safe,
so it is never correct to do a usermode pte update from interrupt context.

Kernel pte updates don't have any particular lock associated with them;
each subsystem generally has its own locking scheme to serialize the
updates if necessary.  Overall the kernel's mappings aren't changed very
often, except for specific things like kmap, vmalloc, page attributes, etc.

So the circumstances you point out would be bugs regardless of whether
Xen or lazy mmu updates are in effect.  Lazy updates rely on those rules
being correctly enforced (in particular, it is never correct to be in
lazy mmu update mode for usermode ptes without holding the pte lock).

    J