[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200710133233.GB2085030@kroah.com>
Date: Fri, 10 Jul 2020 15:32:33 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Jonathan Corbet <corbet@....net>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Guenter Roeck <linux@...ck-us.net>,
Jean Delvare <jdelvare@...e.com>,
linux-doc <linux-doc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-hwmon@...r.kernel.org,
Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH v2 5/6] devres: provide devm_krealloc()
On Mon, Jul 06, 2020 at 06:38:10PM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 2, 2020 at 3:11 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> >
> > On Thu, Jul 2, 2020 at 2:42 PM Greg Kroah-Hartman
> > <gregkh@...uxfoundation.org> wrote:
> > >
> > > On Mon, Jun 29, 2020 at 08:50:07AM +0200, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bgolaszewski@...libre.com>
> > > >
> > > > Implement the managed variant of krealloc(). This function works with
> > > > all memory allocated by devm_kmalloc() (or devres functions using it
> > > > implicitly like devm_kmemdup(), devm_kstrdup() etc.).
> > > >
> > > > Managed realloc'ed chunks can be manually released with devm_kfree().
> > > >
> > > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
> >
> > [snip!]
> >
> > >
> > > That's a lot of logic that does not seem to match up with the krealloc()
> > > logic in mm/slab_common.c, are you sure we need to do all of that?
> > >
> >
> > What are you referring to exactly? The check for rodata? It's because
> > devm_kfree() handles this case, while regular kfree() (or krealloc())
> > doesn't - there's kfree_const() but no devm_kfree_const().
> >
> > > Who wants this?
> >
> > The hwmon commit I mentioned in my response to patch 6/6 explicitly
> > mentions the lack of this helper.
> >
> > Bartosz
>
> Hi Greg,
>
> As we've established in the discussion under the iio patch that there
> will in fact be more users of this - can this now be merged too?
Can you resend the remaining patches, along with the users, and I'll
review it? I just worry about having to duplicate all of that mm code
in there that it will grow stale over time...
thanks,
greg k-h
Powered by blists - more mailing lists