devm_krealloc(9)

📦 version 7.3.1, in nixpkgs unstable

💅 devm_krealloc(9) — from the Kernel API Manual, bestie

okay so picture this: it's giving krealloc() but make it managed ✨ this one lives in the Kernel API Manual and honestly? she's iconic.

🎀 NAME 🎀

devm_krealloc — the resource-managed krealloc(), fr fr. like regular krealloc but the kernel cleans up after you so you don't have to 🫶

✨ SYNOPSIS ✨

void * devm_krealloc (struct device *dev , void *ptr , size_t new_size ,
gfp_t gfp );

that's the whole vibe check right there 👑

🌸 ARGUMENTS 🌸

  • dev — the device you're re-allocating memory for 🏠
  • ptr — pointer to the memory chunk you wanna re-allocate, bestie
  • new_size — the new allocation size, yes we're resizing 💅
  • gfp — the allocation gfp flags ⭐

🦋 DESCRIPTION 🦋

Managed krealloc. she resizes the memory chunk that was allocated with devm_kmalloc. 🎀

Behaves similarly to regular krealloc — and here's the breakdown so you're never confused, iykyk:

  • if ptr is NULL or ZERO_SIZE_PTR, it's the equivalent of devm_kmalloc 💖
  • if new_size is zero, it frees the previously allocated memory and returns ZERO_SIZE_PTR 💀
  • this function doesn't change the order in which the release callback for the re-alloc'ed devres will be called — except when it's falling back to devm_kmalloc or when it's freeing resources when new_size is zero 🙈
  • the contents of the memory are preserved up to the lesser of new and old sizes 🧚 no cap, that part's important
bestie pls note: the release-callback-ordering thing is a real caveat, not just me being dramatic — the order stays the same except in those two fallback/free cases. periodt.

🌈 SEE ALSO 🌈

kernel file ./drivers/base/devres.c and honestly the whole devres friend group 👑

and that's the page, bestie 💜 coming at you from ./drivers/base, dated October 2026 — slay, go free your memory responsibly 🎀✨

📦 where this page comes from