Lines Matching refs:locks
36 on VMA **metadata** so a complicated set of locks are required to ensure memory
45 * **mmap locks** - Each MM has a read/write semaphore :c:member:`!mmap_lock`
46 which locks at a process address space granularity which can be acquired via
48 * **VMA locks** - The VMA lock is at VMA granularity (of course) which behaves
51 write lock via :c:func:`!vma_start_write` (all VMA write locks are unlocked
54 * **rmap locks** - When trying to access VMAs through the reverse mapping via a
60 locks as the reverse mapping locks, or 'rmap locks' for brevity.
62 We discuss page table locks separately in the dedicated section below.
64 The first thing **any** of these locks achieve is to **stabilise** the VMA
99 VMA locks are special in that you must obtain an mmap **write** lock **first**
107 .. note:: The primary users of VMA read locks are page fault handlers, which
131 All of these locks behave as read/write semaphores in practice, so you can
139 This renders read locks on a read/write semaphore concurrent with other
140 readers and write locks exclusive against all others holding the semaphore.
310 rmap locks).
330 locks described in the terminology section above - that is the mmap lock, the
331 VMA lock or either of the reverse mapping locks.
335 operations that perform writes also acquire internal page table locks to
361 As we have multiple locks across the kernel which may or may not be taken at the
362 same time as explicit mm or VMA locks, we have to be wary of lock inversion, and
363 the **order** in which locks are acquired and released becomes very important.
365 .. note:: Lock inversion occurs when two threads need to acquire multiple locks,
372 acquire locks in the same order, one would have waited for the other to
376 ordering of locks within memory management code:
464 In addition to the locks described in the terminology section above, we have
465 additional locks dedicated to page tables:
467 * **Higher level page table locks** - Higher level page tables, that is PGD, P4D
471 * **Fine-grained page table locks** - PMDs and PTEs each have fine-grained locks
478 These locks represent the minimum required to interact with each page table
482 locks are taken. However, at the PTE level, at least concurrent page table
499 * Populating previously empty entries requires that the mmap or VMA locks are
500 held (read or write), doing so with only rmap locks would be dangerous (see
503 stable, that is holding any one of the mmap, VMA or rmap locks.
524 rmap lock for reading in combination with the PTE and PMD page table locks.
548 Regardless of page table locks, the MMU hardware concurrently updates accessed
561 can never assume that page table locks give us entirely exclusive access, and
630 tables as necessary, using these locks to avoid races or overwriting anything,
639 This allows for a traversal with page table locks only being taken when
643 as we have separate PMD and PTE locks and a THP collapse for instance might have
683 cleared without page table locks (in the :c:func:`!pgd_clear`, :c:func:`!p4d_clear`,
689 read lock, PMD, and PTE page table locks, without this level of care.
698 In these instances, it is required that **all** locks are taken, that is
699 the mmap lock, the VMA lock and the relevant rmap locks.
724 VMA read locks increment :c:member:`!vma.vm_refcnt` reference counter for their
728 VMA **write** locks are acquired via :c:func:`!vma_start_write` in instances where a
738 This ensures the semantics we require - VMA write locks provide exclusive write
749 Read locks are acquired via :c:func:`!vma_start_read`, which is an optimistic
779 efficiently release **all** VMA write locks contained within the mmap at the
783 release of any VMA locks on its release makes sense, as you would never want to
804 This way, if any read locks are in effect, :c:func:`!vma_start_write` will sleep
819 mmap (with the usual caveats about requiring VMA write locks to avoid races with
820 tasks holding VMA read locks).
824 implicitly terminates all VMA write locks via :c:func:`!vma_end_write_all`, but
828 An interesting consequence of this is that downgraded locks are exclusive
834 For clarity, we map read (R)/downgraded write (D)/write (W) locks against one
835 another showing which locks exclude the others:
859 Here a Y indicates the locks in the matching row/column are mutually exclusive,