On Wed, Jul 26, 2017 at 08:36:04AM -0400, John Ferlan wrote: > > > On 07/26/2017 04:45 AM, Erik Skultety wrote: > > Commit @4cb719b2dc moved the driver locks around since these have become > > unnecessary at spots where the code handles now self-lockable object > > list, but missed the possible double unlock if udevEnumerateDevices > > fails, because at that point the driver lock had been already dropped. > > > > Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx> > > --- > > src/node_device/node_device_udev.c | 17 ++++++++++------- > > 1 file changed, 10 insertions(+), 7 deletions(-) > > > > Oh yeah - missed that case... thanks. > > w/r/t: _hal from Martin's review - that's pre-existing and separable. > > Still in both cases you're in Initialization functions with an unlock of > an unlocked resource with no error checking by the same thread on your > way to a function that's about to destroy the mutex... and eventual > libvirtd death. Sure, but behaviour of an unlock of an unlocked resource is undefined and we most probably want to terminate the daemon gracefully, or better said, deterministically. Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
