Date: 28 Dec 2010 00:18:07 -0000 From: Colin Percival <cperciva@FreeBSD.org> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/153477: XEN pmap code abuses vm page queue lock Message-ID: <20101228001807.89177.qmail@xps.daemonology.net> Resent-Message-ID: <201012280020.oBS0KCJA013198@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101228001807.89177.qmail>