kern/153477: XEN pmap code abuses vm page queue lock

[Colin Percival]

>Number:         153477
>Category:       kern
>Synopsis:       XEN pmap code abuses vm page queue lock
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Dec 28 00:20:12 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Colin Percival
>Release:        n/a
>Organization:
>Environment:
>Description:

In the FreeBSD/i386 Xen/PV pmap.c code, the vm page queue lock is abused
to control access to the queue of page remapping hypervisor requests.
This lock is asserted in _xen_queue_pt_update in i386/xen/xen_machdep.c,
and this results in it being locked/unlocked a number of times in
i386/xen/pmap.c.  (Judging by the i386 code, there are times when
holding the vm page queue lock in pmap.c is appropriate; but the locking
in pmap_pte and pmap_pte_release is not such an occasion, for example.)

In addition to being subjectively inappropriate, the current locking
creates a LOR between the vm page queue lock and PMAP2mutex.

>How-To-Repeat:

Running 'mdconfig -l' results in a LOR warning being printed.

>Fix:

We should probably have a new xen_pt_update_mtx spin mutex, lock/unlock
it in i386/xen/pmap.c around the page table update calls, and then audit
the vm_page_lock_queues calls to see which can be ripped out.

I'll probably get around to doing this at some point (this PR is mostly
an aide-memoire) but I'd be overjoyed if someone else wants to look at
this first...
>Release-Note:
>Audit-Trail:
>Unformatted: