[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Zp_SNMaCBzonjpcO@pc636>
Date: Tue, 23 Jul 2024 17:54:28 +0200
From: Uladzislau Rezki <urezki@...il.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Uladzislau Rezki <urezki@...il.com>, Danilo Krummrich <dakr@...nel.org>,
cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
iamjoonsoo.kim@....com, akpm@...ux-foundation.org, vbabka@...e.cz,
roman.gushchin@...ux.dev, 42.hyeyoo@...il.com, kees@...nel.org,
ojeda@...nel.org, wedsonaf@...il.com, mhocko@...nel.org,
mpe@...erman.id.au, chandan.babu@...cle.com,
christian.koenig@....com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 1/2] mm: vmalloc: implement vrealloc()
On Tue, Jul 23, 2024 at 06:44:56AM -0700, Christoph Hellwig wrote:
> On Tue, Jul 23, 2024 at 01:28:32PM +0200, Uladzislau Rezki wrote:
> > Concurrent vfree() will lead to use-after-free. Either add a comment
> > that a user is responsible for not using vrealloc()/vfree() on the same
> > pointer concurrently or use find_unlink_vmap_area() which might be more
> > complex when it comes to design of the vrealloc().
>
> You can never use *free concurrently with *realloc. I guess it doesn't
> hurt to clearly document that, but other than that we should not try
> to cater to that use pattern at all.
>
Agree, i mentioned that as a first option. I think, it is enough to document that.
Thanks!
--
Uladzislau Rezki
Powered by blists - more mailing lists