On Sun, Apr 11, 2021 at 5:21 AM Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > Hi Bartosz, > > On Mon, Jun 29, 2020 at 1:56 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > > > > 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
