Re: [PATCH v2 5/6] devres: provide devm_krealloc()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx> wrote:
> >
> > On Thu, Jul 2, 2020 at 2:42 PM Greg Kroah-Hartman
> > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Mon, Jun 29, 2020 at 08:50:07AM +0200, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>
> > > >
> > > > 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@xxxxxxxxxxxx>
> >
> > [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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux