[Bug nptl/16160] New: __lll_robust_trylock is not been implemented correctly in some architecture

[Bug nptl/16160] New: __lll_robust_trylock is not been implemented correctly in some architecture

[wang.deqiang1 at zte dot com.cn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4335 bytes --]

http://sourceware.org/bugzilla/show_bug.cgi?id=16160

            Bug ID: 16160
           Summary: __lll_robust_trylock is not been implemented correctly
                    in some architecture
           Product: glibc
           Version: 2.21
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: wang.deqiang1 at zte dot com.cn
                CC: drepper.fsp at gmail dot com

there's code in __pthread_mutex_trylock:

    case PTHREAD_MUTEX_ROBUST_RECURSIVE_NP:
    case PTHREAD_MUTEX_ROBUST_ERRORCHECK_NP:
    case PTHREAD_MUTEX_ROBUST_NORMAL_NP:
    case PTHREAD_MUTEX_ROBUST_ADAPTIVE_NP:
..................
    oldval = lll_robust_trylock (mutex->__data.__lock, id);
    if (oldval != 0 && (oldval & FUTEX_OWNER_DIED) == 0)
    {
      THREAD_SETMEM (THREAD_SELF, robust_head.list_op_pending, NULL);

      return EBUSY;
    }
    lll_robust_trylock should return the old value of mutex->__data.__lock, if
the old value has FUTEX_OWNER_DIED bit set, then __pthread_mutex_trylock should
goto the beginning of loop to handle the situation that previous owner is
dead。not just return EBUSY.
     x86 and powerpc have the right implementation. but some
architectures(ARM、MIPS.....) implement lll_robust_trylock like this:
/*return old value is 0 or not, not the value*/
static inline int __attribute__((always_inline))
__lll_robust_trylock(int *futex, int id)
{
  return atomic_compare_and_exchange_val_acq (futex, id, 0) != 0;
}
#define lll_robust_trylock(lock, id) \
    then __pthread_mutex_trylock will return EBUSY when previous owner died
just like the mutex is holded by other thread。

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-20132-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Nov 13 03:34:12 2013
Return-Path: <glibc-bugs-return-20132-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 20202 invoked by alias); 13 Nov 2013 03:34:12 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 20175 invoked by uid 48); 13 Nov 2013 03:34:09 -0000
From: "darryl.miles at darrylmiles dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/956] regression: backtrace uses malloc()
Date: Wed, 13 Nov 2013 03:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: darryl.miles at darrylmiles dot org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: gotom at debian dot or.jp
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-956-131-IJcAbaYpra@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-956-131@http.sourceware.org/bugzilla/>
References: <bug-956-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg00103.txt.bz2
Content-length: 555

https://sourceware.org/bugzilla/show_bug.cgi?id•6

Darryl Miles <darryl.miles at darrylmiles dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darryl.miles at darrylmiles dot or
                   |                            |g

--- Comment #9 from Darryl Miles <darryl.miles at darrylmiles dot org> ---
See also Bug#16159

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

[Bug nptl/16160] __lll_robust_trylock is not been implemented correctly in some architecture

[wang.deqiang1 at zte dot com.cn]

http://sourceware.org/bugzilla/show_bug.cgi?id=16160

--- Comment #2 from wangdeqiang <wang.deqiang1 at zte dot com.cn> ---
should i use "atomic_compare_and_exchange_val_acq (futex, id, 0)" to replace
"return atomic_compare_and_exchange_val_acq (futex, id, 0) != 0;" in
__lll_robust_trylock?

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

[Bug nptl/16160] __lll_robust_trylock is not been implemented correctly in some architecture

[wang.deqiang1 at zte dot com.cn]

http://sourceware.org/bugzilla/show_bug.cgi?id=16160

wangdeqiang <wang.deqiang1 at zte dot com.cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wang.deqiang1 at zte dot com.cn

--- Comment #1 from wangdeqiang <wang.deqiang1 at zte dot com.cn> ---
should i use "atomic_compare_and_exchange_val_acq (futex, id, 0)" to replace
"return atomic_compare_and_exchange_val_acq (futex, id, 0) != 0;" in
__lll_robust_trylock?

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