[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zz1nRyMnIaCa0TL5@casper.infradead.org>
Date: Wed, 20 Nov 2024 04:36:23 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: akpm@...ux-foundation.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, minchan@...gle.com, jannh@...gle.com,
shakeel.butt@...ux.dev, souravpanda@...gle.com,
pasha.tatashin@...een.com, corbet@....net,
linux-doc@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH v4 4/5] mm: make vma cache SLAB_TYPESAFE_BY_RCU
On Tue, Nov 19, 2024 at 04:08:25PM -0800, Suren Baghdasaryan wrote:
> +static inline void vma_clear(struct vm_area_struct *vma)
> +{
> + /* Preserve vma->vm_lock */
> + memset(vma, 0, VMA_BEFORE_LOCK);
> + memset(VMA_LOCK_END(vma), 0, VMA_AFTER_LOCK);
> +}
This isn't how you're supposed to handle constructors. You've fixed
the immediate problem rather than writing the code in the intended style.
> +static void vm_area_ctor(void *data)
> +{
> + vma_lock_init(data);
> +}
After the ctor has run, the object should be in the same state as
it is after it's freed. If you want to memset the entire thing
then you can do it in the ctor. But there should be no need to
do it in vma_init().
And there's lots of things you can move from vma_init() to the ctor.
For example, at free time, anon_vma_chain should be an empty list.
So if you init it in the ctor, you can avoid doing it in vma_init().
I'd suggest that vma_numab_state_free() should be the place which
sets vma->numab_state to NULL and we can delete vma_numab_state_init()
entirely.
Powered by blists - more mailing lists