[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0696eaac-943f-4116-b682-f9b15de6aeaf@linux.dev>
Date: Wed, 16 Apr 2025 09:34:30 +0800
From: Ye Liu <ye.liu@...ux.dev>
To: Harry Yoo <harry.yoo@...cle.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Ye Liu <liuye@...inos.cn>
Subject: Re: [PATCH] mm/rmap: Move anon_vma initialization to anon_vma_ctor()
在 2025/4/15 19:28, Harry Yoo 写道:
> On Tue, Apr 15, 2025 at 05:25:48PM +0800, Ye Liu wrote:
>> From: Ye Liu <liuye@...inos.cn>
>>
>> Currently, some initialization of anon_vma is performed in
>> anon_vma_alloc(). Move the initialization to anon_vma_ctor()
>> so that all object setup is handled in one place.
>>
>> Signed-off-by: Ye Liu <liuye@...inos.cn>
>> ---
> NACK unless the patch explains how the object's initial state
> ('constructed state') is preserved between uses.
>
> anon_vma_ctor() is a slab constructor. That means it is called only once
> when a slab (folio) is allocated, and not called again when an anon_vma
> is allocated from an existing slab (folio). In other words it is not called
> everytime an object allocated via kmem_cache_alloc() interface.
Thank you for the feedback. You're absolutely right — I misunderstood
how the slab constructor (ctor) works. I had assumed it would be called
every time an object is allocated via kmem_cache_alloc(), but I now
realize it is only called once when a new slab is initialized, not on
every object allocation.
> This patch looks very dangerous to me and makes me question whether you
> tested it before submission.
>
Appreciate you catching this — and yes, I'll test it more thoroughly
before submitting other patches.
Drop it.
Thanks,
Ye
Powered by blists - more mailing lists