Subject: bug#59055: closed (Re: bug#59055: [PATCH] Fix possible deadlock.)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 20 Nov 2022 17:20:02 +0000

Your bug report

#59055: [PATCH] Fix possible deadlock.

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
59055: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59055
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#59055: [PATCH] Fix possible deadlock.
From: Ludovic Courtès <[email-masked]>
To: Olivier Dion <[email-masked]>
Cc: [email-masked]
Date: Sun, 20 Nov 2022 18:19:07 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

Olivier Dion <[email-masked]> skribis:

> If we got interrupted while waiting on our condition variable, we unlock
> the kernel mutex momentarily while executing asynchronous operations
> before putting us back into the waiting queue.
>
> However, we have to retry acquiring the mutex before getting back into
> the queue, otherwise it's possible that we wait indefinitely since
> nobody could be the owner for a while.
>
> * libguile/threads.c (lock_mutex): Try acquring the mutex after signal
> interruption.

Looks reasonable to me; applied.

Did you try to come up with a reproducer?  That would be awesome but I
guess it’s hard because you need to trigger EINTR at the right point.

Thanks,
Ludo’.

Subject: [PATCH] Fix possible deadlock.
From: Olivier Dion <[email-masked]>
To: [email-masked]
Cc: Olivier Dion <[email-masked]>
Date: Sat, 5 Nov 2022 12:59:23 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

If we got interrupted while waiting on our condition variable, we unlock
the kernel mutex momentarily while executing asynchronous operations
before putting us back into the waiting queue.

However, we have to retry acquiring the mutex before getting back into
the queue, otherwise it's possible that we wait indefinitely since
nobody could be the owner for a while.

* libguile/threads.c (lock_mutex): Try acquring the mutex after signal
interruption.
---
 libguile/threads.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/libguile/threads.c b/libguile/threads.c
index 280d306bf..0f5cf2ed5 100644
--- a/libguile/threads.c
+++ b/libguile/threads.c
@@ -1022,14 +1022,7 @@ lock_mutex (enum scm_mutex_kind kind, struct scm_mutex *m,
 
         if (err == 0)
           {
-            if (scm_is_eq (m->owner, SCM_BOOL_F))
-              {
-                m->owner = current_thread->handle;
-                scm_i_pthread_mutex_unlock (&m->lock);
-                return SCM_BOOL_T;
-              }
-            else
-              continue;
+            goto maybe_acquire;
           }
         else if (err == ETIMEDOUT)
           {
@@ -1041,7 +1034,7 @@ lock_mutex (enum scm_mutex_kind kind, struct scm_mutex *m,
             scm_i_pthread_mutex_unlock (&m->lock);
             scm_async_tick ();
             scm_i_scm_pthread_mutex_lock (&m->lock);
-            continue;
+            goto maybe_acquire;
           }
         else
           {
@@ -1050,6 +1043,14 @@ lock_mutex (enum scm_mutex_kind kind, struct scm_mutex *m,
             errno = err;
             SCM_SYSERROR;
           }
+
+      maybe_acquire:
+        if (scm_is_eq (m->owner, SCM_BOOL_F))
+          {
+            m->owner = current_thread->handle;
+            scm_i_pthread_mutex_unlock (&m->lock);
+            return SCM_BOOL_T;
+          }
       }
 }
 #undef FUNC_NAME
-- 
2.38.0