linux-kernel - Re: [PATCH v7 16/17] mm: make vma cache SLAB_TYPESAFE_BY

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: <CAJuCfpGXShhwxDaGOtAcSZrdH6J=O6RGcuR8tN3Ax0OVMQUupg@mail.gmail.com>
Date: Wed, 8 Jan 2025 10:44:40 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: akpm@...ux-foundation.org, peterz@...radead.org, willy@...radead.org, 
	liam.howlett@...cle.com, lorenzo.stoakes@...cle.com, mhocko@...e.com, 
	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 16/17] mm: make vma cache SLAB_TYPESAFE_BY_RCU

On Wed, Jan 8, 2025 at 10:21 AM Vlastimil Babka <vbabka@...e.cz> wrote:
>
> On 12/26/24 18:07, Suren Baghdasaryan wrote:
> > To enable SLAB_TYPESAFE_BY_RCU for vma cache we need to ensure that
> > object reuse before RCU grace period is over will be detected by
> > lock_vma_under_rcu(). Current checks are sufficient as long as vma
> > is detached before it is freed. Implement this guarantee by calling
> > vma_ensure_detached() before vma is freed and make vm_area_cachep
> > SLAB_TYPESAFE_BY_RCU. This will facilitate vm_area_struct reuse and
> > will minimize the number of call_rcu() calls.
> >
> > Signed-off-by: Suren Baghdasaryan <surenb@...gle.com>
>
> I've noticed vm_area_dup() went back to the approach of "we memcpy
> everything including vma_lock and detached (now the vm_refcnt) followed by a
> vma_init_lock(..., true) that does refcount_set(&vma->vm_refcnt, 0);
> Is that now safe against a racing lock_vma_under_rcu()? I think it's not?

I think it's safe because vma created by vm_area_dup() is not in the
vma tree yet, so lock_vma_under_rcu() does not see it until it's added
into the tree. Note also that at the time when the new vma gets added
into the tree, the vma has to be write-locked
(vma_iter_store()->vma_mark_attached()->vma_assert_write_locked()).
So, lock_vma_under_rcu() won't use the new vma even after it's added
into the tree until we unlock the vma.

>