Messages in this thread | | | From | Bartosz Golaszewski <> | Date | Mon, 12 Apr 2021 21:23:06 +0200 | Subject | Re: [PATCH v2 4/6] devres: handle zero size in devm_kmalloc() |
| |
On Sun, Apr 11, 2021 at 5:21 AM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > Hi Bartosz, > > On Mon, Jun 29, 2020 at 1:56 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > Make devm_kmalloc() behave similarly to non-managed kmalloc(): return > > ZERO_SIZE_PTR when requested size is 0. Update devm_kfree() to handle > > this case. > > This is wrong if you consider devm_krealloc API that you added. The > premise of devm_krealloc() is that it does not disturb devres "stack", > however in this case there is no entry in the stack. Consider: > > ptr = devm_kzalloc(dev, 0, GFP_KERNEL); > ... > more devm API calls > ... > > /* This allocation will be on top of devm stack, not bottom ! */ > ptr = devm_krealloc(dev, ptr, 16, GFP_KERNEL); > > And also: > > ptr = devm_kzalloc(dev, 16, GFP_KERNEL); > ... > more devm API calls > ... > /* Here we lose out position */ > ptr = devm_krealloc(dev, ptr, 0, GFP_KERNEL); > ... > /* and now our memory allocation will be released first */ > ptr = devm_krealloc(dev, ptr, 16, GFP_KERNEL); > > > IMO special-casing 0-size allocations for managed memory allocations > should not be done. > > Thanks. > > -- > Dmitry
You're right about the ordering being lost. At the same time allocating 0 bytes is quite a special case and should result in returning ZERO_SIZE_PTR as the fault dump resulting from its dereference will indicate what the bug is.
I need to give it a thought because I'm not yet sure what the right solution would be. Let me get back to you.
Bartosz
| |