>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: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
