Thread (181 messages) 181 messages, 12 authors, 2023-11-22

Re: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock

From: Suren Baghdasaryan <surenb@google.com>
Date: 2023-01-17 04:35:04
Also in: linux-arm-kernel, linux-mm, lkml

On Mon, Jan 16, 2023 at 8:14 PM Matthew Wilcox [off-list ref] wrote:
On Mon, Jan 16, 2023 at 11:14:38AM +0000, Hyeonggon Yoo wrote:
quoted
quoted
@@ -643,20 +647,28 @@ static inline void vma_write_lock(struct vm_area_struct *vma)
 static inline bool vma_read_trylock(struct vm_area_struct *vma)
 {
    /* Check before locking. A race might cause false locked result. */
-   if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
+   if (vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
            return false;

-   if (unlikely(down_read_trylock(&vma->vm_lock->lock) == 0))
+   if (unlikely(!atomic_inc_unless_negative(&vma->vm_lock->count)))
            return false;

+   /* If atomic_t overflows, restore and fail to lock. */
+   if (unlikely(atomic_read(&vma->vm_lock->count) < 0)) {
+           if (atomic_dec_and_test(&vma->vm_lock->count))
+                   wake_up(&vma->vm_mm->vma_writer_wait);
+           return false;
+   }
+
    /*
     * Overflow might produce false locked result.
     * False unlocked result is impossible because we modify and check
     * vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock_seq
     * modification invalidates all existing locks.
     */
-   if (unlikely(vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) {
-           up_read(&vma->vm_lock->lock);
+   if (unlikely(vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) {
+           if (atomic_dec_and_test(&vma->vm_lock->count))
+                   wake_up(&vma->vm_mm->vma_writer_wait);
            return false;
    }
With this change readers can cause writers to starve.
What about checking waitqueue_active() before or after increasing
vma->vm_lock->count?
I don't understand how readers can starve a writer.  Readers do
atomic_inc_unless_negative() so a writer can always force readers
to fail.
I think the point here was that if page faults keep occuring and they
prevent vm_lock->count from reaching 0 then a writer will be blocked
and there is no reader throttling mechanism (no max time that writer
will be waiting).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help