[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] 2.6.32 PV Xen donU guest panic on nested call to arch_enter_lazy_mmu_mode()



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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.