[Bug nptl/20263] New: robust mutex deadlocks if other thread requests timedlock (Only arm/linux)

["t2wish at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 20263
           Summary: robust mutex deadlocks if other thread requests
                    timedlock (Only arm/linux)
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: t2wish at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 9338
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9338&action=edit
robust mutex test code

This issue occures Linux/arm environment. The same code works well on Linux x64
machine. Please take a look below issue.

When I made a robust mutex and it was owned by A thread. And then B thread
requested to lock the mutex with speicified time. I expected the return value
is ETIMEOUT because it was already owned by A thread but the real result is
daedlock.
I attached my test code and below are results.

Ubuntu x64
$ ./a
[17303] (90) Init Mutex Attribute
[17303] (105) Init Mutex
[17304] (17) Start Child...
[17304] (19) Lock Mutex
[17305] (50) Start Parent...
[17305] (52) Lock pp Mutex
[17305] (55) Acquire pp Mutex
[17304] (22) Acquire Mutex
[17305] (63) Timedlock...
[17304] (28) Trylock...
[17304] (28) Trylock...
[17304] (28) Trylock...
[17304] (28) Trylock...
[17304] (28) Trylock...
[17304] (28) Trylock...
[17304] (28) Trylock...
[17304] (28) Trylock...
[17304] (28) Trylock...
[17304] (28) Trylock...
[17305] (65) ret : 110
[17305] (67) Timedlock... ETIMEDOUT
[17305] (76) Unlock pp Mutex
[17305] (81) End Parent
[17304] (28) Trylock...
[17304] (31) Trylock... Lock!!!
[17304] (37) Unlock pp Mutex
[17304] (42) End Child

Raspberry PI results.

bash-3.2# ./a
[17312] (90) Init Mutex Attribute
[17312] (105) Init Mutex
[17313] (17) Start Child...
[17313] (19) Lock Mutex
[17313] (22) Acquire Mutex
[17314] (50) Start Parent...
[17314] (52) Lock pp Mutex
[17314] (55) Acquire pp Mutex
[17313] (28) Trylock...
[17314] (63) Timedlock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
[17313] (28) Trylock...
^C

Ubuntu x64 successfully caught the ETIMEOUT error but raspberry pi hangs.
This issue is related to __lll_robust_timedlock_wait function.
After waiting the locked mutex in a specified time, I think it should be break
the while loop by 121 line. But after passing the line, the oldval is the same
value with newval and it makes daedlock.


62int
63__lll_robust_timedlock_wait (int *futex, const struct timespec *abstime,
64                           int private)
65{
66  /* Reject invalid timeouts.  */
67  if (abstime->tv_nsec < 0 || abstime->tv_nsec >= 1000000000)
68    return EINVAL;
69
70  int tid = THREAD_GETMEM (THREAD_SELF, tid);
71  int oldval = *futex;
72
73  /* If the futex changed meanwhile, try locking again.  */
74  if (oldval == 0)
75    goto try;
76
77  /* Work around the fact that the kernel rejects negative timeout values
78     despite them being valid.  */
79  if (__glibc_unlikely (abstime->tv_sec < 0))
80    return ETIMEDOUT;
81
82  do
83    {
105
106      /* If the owner died, return the present value of the futex.  */
107      if (__glibc_unlikely (oldval & FUTEX_OWNER_DIED))
108     return oldval;
109
110      /* Try to put the lock into state 'acquired, possibly with waiters'. 
*/
111      int newval = oldval | FUTEX_WAITERS;
112      if (oldval != newval
113       && atomic_compare_and_exchange_bool_acq (futex, newval, oldval))
114     continue;
115
116      /* If *futex == 2, wait until woken or timeout.  */
121      lll_futex_timed_wait_bitset (futex, newval, abstime,
122                                FUTEX_CLOCK_REALTIME, private);
124
125    try:
126      ;
127    }
128  while ((oldval = atomic_compare_and_exchange_val_acq (futex,
129                                                     tid | FUTEX_WAITERS,
130                                                     0)) != 0);

Should I need to do more thing to use robust mutex?
Or please give me a hint to fix it.
Thank you.

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