[Bug nptl/21778] New: robust may deadlock

["ma.jiang at zte dot com.cn" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21778

            Bug ID: 21778
           Summary: robust may deadlock
           Product: glibc
           Version: 2.26
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: ma.jiang at zte dot com.cn
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

HI all,
  We found a bug in pthread_mutex_lock which may lead to deadlock. See the
analyze below for details.

__pthread_mutex_lock_full in pthread_mutex_lock.c:
      while (1)
        {
          /* Try to acquire the lock through a CAS from 0 (not acquired) to
             our TID | assume_other_futex_waiters.  */
//oldval=0, and mutex->__data.__lock != 0
          if (__glibc_likely ((oldval == 0)
                              && (atomic_compare_and_exchange_bool_acq
                                  (&mutex->__data.__lock,
                                   id | assume_other_futex_waiters, 0) == 0)))
              break;
//oldval=0, skip
          if ((oldval & FUTEX_OWNER_DIED) != 0)
            {

            }
//oldval=0, skip
          if (__glibc_unlikely ((oldval & FUTEX_TID_MASK) == id))
            {

            }

//oldval=0,  put 0|FUTEX_WAITER into lock when mutex->__data.__lock is 0
//from now on, no one could unlock this mutex...
          if ((oldval & FUTEX_WAITERS) == 0)
            {
              if (atomic_compare_and_exchange_bool_acq (&mutex->__data.__lock,
                                                        oldval | FUTEX_WAITERS,
                                                        oldval)
                  != 0)
                ...
            }

...
        }
  To fix the bug, we should check if oldval=0 before we try to add FUTEX_WAITER
to the lock.
  By the way,There are another similar logical error in pthread_mutex_timedlock
which should fix as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.