On 09/17/2012 03:48 AM, Laine Stump wrote: > virNetworkAssignDef was allocating a new network object, initing and > grabbing its lock, then potentially freeing it without unlocking or > destroying the lock. In practice 1) this will probably never happen, > and 2) even if it did, the lock implementation used on most (all?) This is probably a safe claim for Unix-like systems, but mingw can be rather surprising, and I think actually leaks resources in this scenario. > platforms doesn't actually hold any resources for an initialized or > held lock, but it still bothered me, so I moved the realloc that could > lead to this bad situation earlier in the function, and now the mutex > isn't inited or locked until we are assured of complete success. > --- > src/conf/network_conf.c | 11 +++++------ > 1 file changed, 5 insertions(+), 6 deletions(-) ACK. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list