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

Re: [libvirt PATCH 3/3] util: bitmap: use g_new0/g_free



On 8/4/20 5:09 AM, Daniel P. Berrangé wrote:
On Mon, Aug 03, 2020 at 07:29:19PM +0200, Peter Krempa wrote:
On Mon, Aug 03, 2020 at 19:18:53 +0200, Ján Tomko wrote:
Signed-off-by: Ján Tomko <jtomko redhat com>
---
  src/util/virbitmap.c | 20 ++++++--------------
  1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/src/util/virbitmap.c b/src/util/virbitmap.c
index 4c205016ff..f7dd5d05ad 100644
--- a/src/util/virbitmap.c
+++ b/src/util/virbitmap.c
[...]

@@ -126,10 +121,9 @@ virBitmapNewEmpty(void)
  void
  virBitmapFree(virBitmapPtr bitmap)
  {
-    if (bitmap) {
-        VIR_FREE(bitmap->map);
-        VIR_FREE(bitmap);
-    }
+    if (bitmap)
+        g_free(bitmap->map);
Preferrably keep this VIR_FREE or it's expansion to g_clear_pointer. If
a caller uses a stale pointer, it will crash on dereferencing this part.
There's no strong reason to do that in a vir*Free() function, since
'bitmap' itself is being freed.


I think he was pointing out that if you zero out the contents of the virBitmap object before you free it, then a caller who mistakenly keeps around a pointer to "bitmap" after calling virBitmapFree(bitmap), and then attempts to use it, thus causing a dereference of bitmap->map, will get an immediate segfault rather than using some chunk of memory that may have already been allocated to something else.


This is a useful concept, but unless we do it *everywhere*, making a special case here and there isn't going to have much effect (that was the implication of my original response) - it's kind of emptying the ocean with a tea spoon. (and also it makes the code uglier and more confusing). Now if we could efficiently zero out all blocks of memory as they were freed, then maybe there would be some real bug catching value.



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