libvirt/src/util/virmacmap.c

402 lines
8.5 KiB
C
Raw Normal View History

/*
* virmacmap.c: MAC address <-> Domain name mapping
*
* Copyright (C) 2016 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <http://www.gnu.org/licenses/>.
*
* Authors:
* Michal Privoznik <mprivozn@redhat.com>
*/
#include <config.h>
#include "virmacmap.h"
#include "virobject.h"
#include "virlog.h"
#include "virjson.h"
#include "virfile.h"
#include "virhash.h"
#include "virstring.h"
#include "viralloc.h"
#define VIR_FROM_THIS VIR_FROM_NETWORK
VIR_LOG_INIT("util.virmacmap");
/**
* VIR_MAC_MAP_FILE_SIZE_MAX:
*
* Macro providing the upper limit on the size of mac maps file
*/
#define VIR_MAC_MAP_FILE_SIZE_MAX (32 * 1024 * 1024)
struct virMacMap {
virObjectLockable parent;
virHashTablePtr macs;
};
static virClassPtr virMacMapClass;
virmacmap: Don't use hash table dataFree callback Due to nature of operations we do over the string list (more precisely due to how virStringListRemove() works), it is not the best idea to use dataFree callback. Problem is, on MAC address remove, the string list remove function modifies the original list in place. Then, virHashUpdateEntry() is called which frees all the data stored in the list rendering @newMacsList point to freed data. ==16002== Invalid read of size 8 ==16002== at 0x50BC083: virFree (viralloc.c:582) ==16002== by 0x513DC39: virStringListFree (virstring.c:251) ==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67) ==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352) ==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415) ==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) ==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd ==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693) ==16002== by 0x50BB99B: virReallocN (viralloc.c:245) ==16002== by 0x513DC0B: virStringListRemove (virstring.c:235) ==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-02 09:35:33 +00:00
static int
virMacMapHashFree(void *payload,
const void *name ATTRIBUTE_UNUSED,
void *opaque ATTRIBUTE_UNUSED)
{
virmacmap: Don't use hash table dataFree callback Due to nature of operations we do over the string list (more precisely due to how virStringListRemove() works), it is not the best idea to use dataFree callback. Problem is, on MAC address remove, the string list remove function modifies the original list in place. Then, virHashUpdateEntry() is called which frees all the data stored in the list rendering @newMacsList point to freed data. ==16002== Invalid read of size 8 ==16002== at 0x50BC083: virFree (viralloc.c:582) ==16002== by 0x513DC39: virStringListFree (virstring.c:251) ==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67) ==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352) ==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415) ==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) ==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd ==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693) ==16002== by 0x50BB99B: virReallocN (viralloc.c:245) ==16002== by 0x513DC0B: virStringListRemove (virstring.c:235) ==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-02 09:35:33 +00:00
virStringListFree(payload);
return 0;
}
static void
virmacmap: Don't use hash table dataFree callback Due to nature of operations we do over the string list (more precisely due to how virStringListRemove() works), it is not the best idea to use dataFree callback. Problem is, on MAC address remove, the string list remove function modifies the original list in place. Then, virHashUpdateEntry() is called which frees all the data stored in the list rendering @newMacsList point to freed data. ==16002== Invalid read of size 8 ==16002== at 0x50BC083: virFree (viralloc.c:582) ==16002== by 0x513DC39: virStringListFree (virstring.c:251) ==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67) ==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352) ==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415) ==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) ==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd ==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693) ==16002== by 0x50BB99B: virReallocN (viralloc.c:245) ==16002== by 0x513DC0B: virStringListRemove (virstring.c:235) ==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-02 09:35:33 +00:00
virMacMapDispose(void *obj)
{
virmacmap: Don't use hash table dataFree callback Due to nature of operations we do over the string list (more precisely due to how virStringListRemove() works), it is not the best idea to use dataFree callback. Problem is, on MAC address remove, the string list remove function modifies the original list in place. Then, virHashUpdateEntry() is called which frees all the data stored in the list rendering @newMacsList point to freed data. ==16002== Invalid read of size 8 ==16002== at 0x50BC083: virFree (viralloc.c:582) ==16002== by 0x513DC39: virStringListFree (virstring.c:251) ==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67) ==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352) ==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415) ==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) ==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd ==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693) ==16002== by 0x50BB99B: virReallocN (viralloc.c:245) ==16002== by 0x513DC0B: virStringListRemove (virstring.c:235) ==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-02 09:35:33 +00:00
virMacMapPtr mgr = obj;
virHashForEach(mgr->macs, virMacMapHashFree, NULL);
virHashFree(mgr->macs);
}
static int virMacMapOnceInit(void)
{
if (!VIR_CLASS_NEW(virMacMap, virClassForObjectLockable()))
return -1;
return 0;
}
VIR_ONCE_GLOBAL_INIT(virMacMap);
static int
virMacMapAddLocked(virMacMapPtr mgr,
const char *domain,
const char *mac)
{
int ret = -1;
virmacmap: Don't use hash table dataFree callback Due to nature of operations we do over the string list (more precisely due to how virStringListRemove() works), it is not the best idea to use dataFree callback. Problem is, on MAC address remove, the string list remove function modifies the original list in place. Then, virHashUpdateEntry() is called which frees all the data stored in the list rendering @newMacsList point to freed data. ==16002== Invalid read of size 8 ==16002== at 0x50BC083: virFree (viralloc.c:582) ==16002== by 0x513DC39: virStringListFree (virstring.c:251) ==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67) ==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352) ==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415) ==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) ==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd ==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693) ==16002== by 0x50BB99B: virReallocN (viralloc.c:245) ==16002== by 0x513DC0B: virStringListRemove (virstring.c:235) ==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-02 09:35:33 +00:00
char **macsList = NULL;
char **newMacsList = NULL;
if ((macsList = virHashLookup(mgr->macs, domain)) &&
virmacmap: Don't use hash table dataFree callback Due to nature of operations we do over the string list (more precisely due to how virStringListRemove() works), it is not the best idea to use dataFree callback. Problem is, on MAC address remove, the string list remove function modifies the original list in place. Then, virHashUpdateEntry() is called which frees all the data stored in the list rendering @newMacsList point to freed data. ==16002== Invalid read of size 8 ==16002== at 0x50BC083: virFree (viralloc.c:582) ==16002== by 0x513DC39: virStringListFree (virstring.c:251) ==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67) ==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352) ==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415) ==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) ==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd ==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693) ==16002== by 0x50BB99B: virReallocN (viralloc.c:245) ==16002== by 0x513DC0B: virStringListRemove (virstring.c:235) ==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-02 09:35:33 +00:00
virStringListHasString((const char**) macsList, mac)) {
ret = 0;
goto cleanup;
}
virmacmap: Don't use hash table dataFree callback Due to nature of operations we do over the string list (more precisely due to how virStringListRemove() works), it is not the best idea to use dataFree callback. Problem is, on MAC address remove, the string list remove function modifies the original list in place. Then, virHashUpdateEntry() is called which frees all the data stored in the list rendering @newMacsList point to freed data. ==16002== Invalid read of size 8 ==16002== at 0x50BC083: virFree (viralloc.c:582) ==16002== by 0x513DC39: virStringListFree (virstring.c:251) ==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67) ==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352) ==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415) ==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) ==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd ==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693) ==16002== by 0x50BB99B: virReallocN (viralloc.c:245) ==16002== by 0x513DC0B: virStringListRemove (virstring.c:235) ==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-02 09:35:33 +00:00
if (!(newMacsList = virStringListAdd((const char **) macsList, mac)) ||
virHashUpdateEntry(mgr->macs, domain, newMacsList) < 0)
goto cleanup;
newMacsList = NULL;
virmacmap: Don't use hash table dataFree callback Due to nature of operations we do over the string list (more precisely due to how virStringListRemove() works), it is not the best idea to use dataFree callback. Problem is, on MAC address remove, the string list remove function modifies the original list in place. Then, virHashUpdateEntry() is called which frees all the data stored in the list rendering @newMacsList point to freed data. ==16002== Invalid read of size 8 ==16002== at 0x50BC083: virFree (viralloc.c:582) ==16002== by 0x513DC39: virStringListFree (virstring.c:251) ==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67) ==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352) ==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415) ==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) ==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd ==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693) ==16002== by 0x50BB99B: virReallocN (viralloc.c:245) ==16002== by 0x513DC0B: virStringListRemove (virstring.c:235) ==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-02 09:35:33 +00:00
virStringListFree(macsList);
ret = 0;
cleanup:
virStringListFree(newMacsList);
return ret;
}
static int
virMacMapRemoveLocked(virMacMapPtr mgr,
const char *domain,
const char *mac)
{
char **macsList = NULL;
char **newMacsList = NULL;
if (!(macsList = virHashLookup(mgr->macs, domain)))
return 0;
newMacsList = macsList;
virStringListRemove(&newMacsList, mac);
if (!newMacsList) {
virHashSteal(mgr->macs, domain);
} else {
if (macsList != newMacsList &&
virHashUpdateEntry(mgr->macs, domain, newMacsList) < 0)
return -1;
}
return 0;
}
static int
virMacMapLoadFile(virMacMapPtr mgr,
const char *file)
{
char *map_str = NULL;
virJSONValuePtr map = NULL;
int map_str_len = 0;
size_t i;
int ret = -1;
if (virFileExists(file) &&
(map_str_len = virFileReadAll(file,
VIR_MAC_MAP_FILE_SIZE_MAX,
&map_str)) < 0)
goto cleanup;
if (map_str_len == 0) {
ret = 0;
goto cleanup;
}
if (!(map = virJSONValueFromString(map_str))) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("invalid json in file: %s"),
file);
goto cleanup;
}
if (!virJSONValueIsArray(map)) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Malformed file structure: %s"),
file);
goto cleanup;
}
for (i = 0; i < virJSONValueArraySize(map); i++) {
virJSONValuePtr tmp = virJSONValueArrayGet(map, i);
virJSONValuePtr macs;
const char *domain;
size_t j;
if (!(domain = virJSONValueObjectGetString(tmp, "domain"))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Missing domain"));
goto cleanup;
}
if (!(macs = virJSONValueObjectGetArray(tmp, "macs"))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Missing macs"));
goto cleanup;
}
for (j = 0; j < virJSONValueArraySize(macs); j++) {
virJSONValuePtr macJSON = virJSONValueArrayGet(macs, j);
const char *mac = virJSONValueGetString(macJSON);
if (virMacMapAddLocked(mgr, domain, mac) < 0)
goto cleanup;
}
}
ret = 0;
cleanup:
VIR_FREE(map_str);
virJSONValueFree(map);
return ret;
}
static int
virMACMapHashDumper(void *payload,
const void *name,
void *data)
{
virJSONValuePtr obj = NULL;
virJSONValuePtr arr = NULL;
const char **macs = payload;
size_t i;
int ret = -1;
if (!(obj = virJSONValueNewObject()) ||
!(arr = virJSONValueNewArray()))
goto cleanup;
for (i = 0; macs[i]; i++) {
virJSONValuePtr m = virJSONValueNewString(macs[i]);
if (!m ||
virJSONValueArrayAppend(arr, m) < 0) {
virJSONValueFree(m);
goto cleanup;
}
}
if (virJSONValueObjectAppendString(obj, "domain", name) < 0 ||
virJSONValueObjectAppend(obj, "macs", arr) < 0)
goto cleanup;
arr = NULL;
if (virJSONValueArrayAppend(data, obj) < 0)
goto cleanup;
obj = NULL;
ret = 0;
cleanup:
virJSONValueFree(obj);
virJSONValueFree(arr);
return ret;
}
static int
virMacMapDumpStrLocked(virMacMapPtr mgr,
char **str)
{
virJSONValuePtr arr;
int ret = -1;
if (!(arr = virJSONValueNewArray()))
goto cleanup;
if (virHashForEach(mgr->macs, virMACMapHashDumper, arr) < 0)
goto cleanup;
if (!(*str = virJSONValueToString(arr, true)))
goto cleanup;
ret = 0;
cleanup:
virJSONValueFree(arr);
return ret;
}
static int
virMacMapWriteFileLocked(virMacMapPtr mgr,
const char *file)
{
char *str;
int ret = -1;
if (virMacMapDumpStrLocked(mgr, &str) < 0)
goto cleanup;
if (virFileRewriteStr(file, 0644, str) < 0)
goto cleanup;
ret = 0;
cleanup:
VIR_FREE(str);
return ret;
}
char *
virMacMapFileName(const char *dnsmasqStateDir,
const char *bridge)
{
char *filename;
ignore_value(virAsprintf(&filename, "%s/%s.macs", dnsmasqStateDir, bridge));
return filename;
}
#define VIR_MAC_HASH_TABLE_SIZE 10
virMacMapPtr
virMacMapNew(const char *file)
{
virMacMapPtr mgr;
if (virMacMapInitialize() < 0)
return NULL;
if (!(mgr = virObjectLockableNew(virMacMapClass)))
return NULL;
virObjectLock(mgr);
virmacmap: Don't use hash table dataFree callback Due to nature of operations we do over the string list (more precisely due to how virStringListRemove() works), it is not the best idea to use dataFree callback. Problem is, on MAC address remove, the string list remove function modifies the original list in place. Then, virHashUpdateEntry() is called which frees all the data stored in the list rendering @newMacsList point to freed data. ==16002== Invalid read of size 8 ==16002== at 0x50BC083: virFree (viralloc.c:582) ==16002== by 0x513DC39: virStringListFree (virstring.c:251) ==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67) ==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352) ==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415) ==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) ==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd ==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693) ==16002== by 0x50BB99B: virReallocN (viralloc.c:245) ==16002== by 0x513DC0B: virStringListRemove (virstring.c:235) ==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124) ==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346) ==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107) ==16002== by 0x403F15: virTestRun (testutils.c:180) ==16002== by 0x4032C4: mymain (virmacmaptest.c:205) ==16002== by 0x405A3B: virTestMain (testutils.c:992) ==16002== by 0x403D87: main (virmacmaptest.c:237) Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-02 09:35:33 +00:00
if (!(mgr->macs = virHashCreate(VIR_MAC_HASH_TABLE_SIZE, NULL)))
goto error;
if (file &&
virMacMapLoadFile(mgr, file) < 0)
goto error;
virObjectUnlock(mgr);
return mgr;
error:
virObjectUnlock(mgr);
virObjectUnref(mgr);
return NULL;
}
int
virMacMapAdd(virMacMapPtr mgr,
const char *domain,
const char *mac)
{
int ret;
virObjectLock(mgr);
ret = virMacMapAddLocked(mgr, domain, mac);
virObjectUnlock(mgr);
return ret;
}
int
virMacMapRemove(virMacMapPtr mgr,
const char *domain,
const char *mac)
{
int ret;
virObjectLock(mgr);
ret = virMacMapRemoveLocked(mgr, domain, mac);
virObjectUnlock(mgr);
return ret;
}
const char *const *
virMacMapLookup(virMacMapPtr mgr,
const char *domain)
{
const char *const *ret;
virObjectLock(mgr);
ret = virHashLookup(mgr->macs, domain);
virObjectUnlock(mgr);
return ret;
}
int
virMacMapWriteFile(virMacMapPtr mgr,
const char *filename)
{
int ret;
virObjectLock(mgr);
ret = virMacMapWriteFileLocked(mgr, filename);
virObjectUnlock(mgr);
return ret;
}
int
virMacMapDumpStr(virMacMapPtr mgr,
char **str)
{
int ret;
virObjectLock(mgr);
ret = virMacMapDumpStrLocked(mgr, str);
virObjectUnlock(mgr);
return ret;
}