288 /* * Maps are doubly-linked lists of map entries, kept sorted * by address. A single hint is provided to start * searches again from the last successful search, * insertion, or removal. * * LOCKING PROTOCOL NOTES: * ----------------------- * * VM map locking is a little complicated. There are both shared * and exclusive locks on maps. However, it is sometimes required * to downgrade an exclusive lock to a shared lock, and upgrade to * an exclusive lock again (to perform error recovery). However, * another thread *must not* queue itself to receive an exclusive * lock while before we upgrade back to exclusive, otherwise the * error recovery becomes extremely difficult, if not impossible. * * In order to prevent this scenario, we introduce the notion of * a `busy' map. A `busy' map is read-locked, but other threads * attempting to write-lock wait for this flag to clear before * entering the lock manager. A map may only be marked busy * when the map is write-locked (and then the map must be downgraded * to read-locked), and may only be marked unbusy by the thread * which marked it busy (holding *either* a read-lock or a * write-lock, the latter being gained by an upgrade). * * Access to the map `flags' member is controlled by the `flags_lock' * simple lock. Note that some flags are static (set once at map * creation time, and never changed), and thus require no locking * to check those flags. All flags which are r/w must be set or * cleared while the `flags_lock' is asserted. Additional locking * requirements are: * * VM_MAP_PAGEABLE r/o static flag; no locking required * * VM_MAP_WIREFUTURE r/w; may only be set or cleared when * map is write-locked. may be tested * without asserting `flags_lock'. * * VM_MAP_DYING r/o; set when a vmspace is being * destroyed to indicate that updates * to the pmap can be skipped. * * VM_MAP_TOPDOWN r/o; set when the vmspace is * created if the unspecified map * allocations are to be arranged in * a "top down" manner. */