[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zp-4l4ARjzVyDUvH@pollux>
Date: Tue, 23 Jul 2024 16:05:11 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
iamjoonsoo.kim@....com, vbabka@...e.cz, roman.gushchin@...ux.dev,
42.hyeyoo@...il.com, urezki@...il.com, hch@...radead.org,
kees@...nel.org, ojeda@...nel.org, wedsonaf@...il.com,
mhocko@...nel.org, mpe@...erman.id.au, chandan.babu@...cle.com,
christian.koenig@....com, maz@...nel.org, oliver.upton@...ux.dev,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v2 2/2] mm: kvmalloc: align kvrealloc() with krealloc()
On Mon, Jul 22, 2024 at 06:43:48PM -0700, Andrew Morton wrote:
> On Mon, 22 Jul 2024 18:29:24 +0200 Danilo Krummrich <dakr@...nel.org> wrote:
>
> > Besides the obvious (and desired) difference between krealloc() and
> > kvrealloc(), there is some inconsistency in their function signatures
> > and behavior:
> >
> > - krealloc() frees the memory when the requested size is zero, whereas
> > kvrealloc() simply returns a pointer to the existing allocation.
>
> The old kvrealloc() behavior actually sounds somewhat useful. You've
> checked that no existing sites were relying on this?
Yes, I did.
>
> And that all existing kvrealloc() callers were (incorrectly) checking
> for NULL? Seems that way.
You mean for the initial allocation? Yes, but I also noticed that as long as the
old kvrealloc() is called with p == NULL and oldsize == 0 it should work as
well.
Powered by blists - more mailing lists