lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJuCfpE+kzSO4ei3jmKEn_nu=xETBwDu73C=izPJy6y+4wGx7Q@mail.gmail.com>
Date: Mon, 6 Jan 2025 09:26:18 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: Wei Yang <richard.weiyang@...il.com>
Cc: akpm@...ux-foundation.org, peterz@...radead.org, willy@...radead.org, 
	liam.howlett@...cle.com, lorenzo.stoakes@...cle.com, mhocko@...e.com, 
	vbabka@...e.cz, hannes@...xchg.org, mjguzik@...il.com, oliver.sang@...el.com, 
	mgorman@...hsingularity.net, david@...hat.com, peterx@...hat.com, 
	oleg@...hat.com, dave@...olabs.net, paulmck@...nel.org, brauner@...nel.org, 
	dhowells@...hat.com, hdanton@...a.com, hughd@...gle.com, 
	lokeshgidra@...gle.com, minchan@...gle.com, jannh@...gle.com, 
	shakeel.butt@...ux.dev, souravpanda@...gle.com, pasha.tatashin@...een.com, 
	klarasmodin@...il.com, corbet@....net, linux-doc@...r.kernel.org, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH v7 12/17] mm: replace vm_lock and detached flag with a
 reference count

On Sun, Jan 5, 2025 at 4:38 PM Wei Yang <richard.weiyang@...il.com> wrote:
>
> On Thu, Dec 26, 2024 at 09:07:04AM -0800, Suren Baghdasaryan wrote:
> [...]
> > /*
> >  * Try to read-lock a vma. The function is allowed to occasionally yield false
> >  * locked result to avoid performance overhead, in which case we fall back to
> >@@ -710,6 +733,8 @@ static inline void vma_lock_init(struct vm_area_struct *vma)
> >  */
> > static inline bool vma_start_read(struct vm_area_struct *vma)
> > {
> >+      int oldcnt;
> >+
> >       /*
> >        * Check before locking. A race might cause false locked result.
> >        * We can use READ_ONCE() for the mm_lock_seq here, and don't need
> >@@ -720,13 +745,20 @@ static inline bool vma_start_read(struct vm_area_struct *vma)
> >       if (READ_ONCE(vma->vm_lock_seq) == READ_ONCE(vma->vm_mm->mm_lock_seq.sequence))
> >               return false;
> >
> >-      if (unlikely(down_read_trylock(&vma->vm_lock.lock) == 0))
> >+
> >+      rwsem_acquire_read(&vma->vmlock_dep_map, 0, 0, _RET_IP_);
> >+      /* Limit at VMA_REF_LIMIT to leave one count for a writer */
> >+      if (unlikely(!__refcount_inc_not_zero_limited(&vma->vm_refcnt, &oldcnt,
> >+                                                    VMA_REF_LIMIT))) {
> >+              rwsem_release(&vma->vmlock_dep_map, _RET_IP_);
> >               return false;
> >+      }
> >+      lock_acquired(&vma->vmlock_dep_map, _RET_IP_);
> >
> >       /*
> >-       * Overflow might produce false locked result.
> >+       * Overflow of vm_lock_seq/mm_lock_seq 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
> >+       * vma->vm_lock_seq under vma->vm_refcnt protection and mm->mm_lock_seq
> >        * modification invalidates all existing locks.
> >        *
> >        * We must use ACQUIRE semantics for the mm_lock_seq so that if we are
> >@@ -734,10 +766,12 @@ static inline bool vma_start_read(struct vm_area_struct *vma)
> >        * after it has been unlocked.
> >        * This pairs with RELEASE semantics in vma_end_write_all().
> >        */
> >-      if (unlikely(vma->vm_lock_seq == raw_read_seqcount(&vma->vm_mm->mm_lock_seq))) {
> >-              up_read(&vma->vm_lock.lock);
> >+      if (unlikely(oldcnt & VMA_LOCK_OFFSET ||
> >+                   vma->vm_lock_seq == raw_read_seqcount(&vma->vm_mm->mm_lock_seq))) {
>
> I am not sure it worth mention. In case it is too trivial, just ignore.
>
> If (oldcnt & VMA_LOCK_OFFSET), oldcnt + 1 > VMA_REF_LIMIT. This means
> __refcount_inc_not_zero_limited() above would return false.
>
> If my understanding is correct, we don't need to check it here.

Yes, you are correct, (oldcnt & VMA_LOCK_OFFSET) is not really needed
here. I'll send a small fixup removing this check and adding a comment
before __refcount_inc_not_zero_limited() explaining that it will fail
if VMA_LOCK_OFFSET is set.
Thanks,
Suren.

>
> >+              vma_refcount_put(vma);
> >               return false;
> >       }
> >+
> >       return true;
> > }
> >
> [...]
>
> --
> Wei Yang
> Help you, Help me

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ