From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bart Van Assche Subject: [PATCH 2/2] multipathd: Avoid that a deadlock is triggered sporadically during shutdown Date: Fri, 14 Oct 2016 08:35:47 -0700 Message-ID: <5832949e-aa89-ebf2-11e1-67bbb4d050bf@sandisk.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Christophe Varoqui Cc: device-mapper development List-Id: dm-devel.ids pthread_cond_wait() is a thread cancellation point. If a thread that is waiting in pthread_cond_wait() is canceled it is possible that the mutex is re-acquired before the first cancellation cleanup handler is called. In this case the cleanup handler is uevq_stop() and that function locks uevq_lock. Avoid that calling uevq_stop() results in a deadlock due to an attempt to lock a non-recursive mutex recursively. Signed-off-by: Bart Van Assche --- libmultipath/uevent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libmultipath/uevent.c b/libmultipath/uevent.c index 6247898..85fd2fb 100644 --- a/libmultipath/uevent.c +++ b/libmultipath/uevent.c @@ -52,7 +52,7 @@ typedef int (uev_trigger)(struct uevent *, void * trigger_data); pthread_t uevq_thr; LIST_HEAD(uevq); -pthread_mutex_t uevq_lock = PTHREAD_MUTEX_INITIALIZER; +pthread_mutex_t uevq_lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP; pthread_mutex_t *uevq_lockp = &uevq_lock; pthread_cond_t uev_cond = PTHREAD_COND_INITIALIZER; pthread_cond_t *uev_condp = &uev_cond; -- 2.10.0