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(a)redhat.com>
> ---
> 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