[Bug nptl/17561] New: GLIBC 2.20 results in SIGILL on x86_64 with double pthread_rwlock_unlock()

[Bug nptl/17561] New: GLIBC 2.20 results in SIGILL on x86_64 with double pthread_rwlock_unlock()

[aaro.koskinen at iki dot fi]

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

            Bug ID: 17561
           Summary: GLIBC 2.20 results in SIGILL on x86_64 with double
                    pthread_rwlock_unlock()
           Product: glibc
           Version: 2.20
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: aaro.koskinen at iki dot fi
                CC: drepper.fsp at gmail dot com

The following program fails with illegal instruction on x86_64 on HW where
_xend() is not supported (even if it would the behaviour is not probably
correct):

$ cat foo.c
#include <pthread.h>
#include <stdio.h>

int main(void)
{
        pthread_rwlock_t _lock;

        pthread_rwlock_init(&_lock, 0);
        pthread_rwlock_wrlock(&_lock);
        pthread_rwlock_unlock(&_lock);
        pthread_rwlock_unlock(&_lock);
        pthread_rwlock_destroy(&_lock);
        return 0;
}
$ gcc foo.c -lpthread
$ ./a.out
Illegal instruction

This is caused by __pthread_rwlock_unlock() -> ELIDE_UNLOCK() -> _xend()

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

[Bug nptl/17561] GLIBC 2.20 results in SIGILL on x86_64 with double pthread_rwlock_unlock()

[aaro.koskinen at iki dot fi]

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

Aaro Koskinen <aaro.koskinen at iki dot fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-linux-gnu
               Host|                            |x86_64-linux-gnu
              Build|                            |x86_64-linux-gnu

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

[Bug nptl/17561] GLIBC 2.20 results in SIGILL on x86_64 with double pthread_rwlock_unlock()

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fweimer at redhat dot com
         Resolution|---                         |INVALID
              Flags|                            |security-

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
This test case is invalid.  Calling pthread_rwlock_unlock on an rwlock which is
not locked is undefined.

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

[Bug nptl/17561] GLIBC 2.20 results in SIGILL on x86_64 with double pthread_rwlock_unlock()

[aaro.koskinen at iki dot fi]

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

--- Comment #2 from Aaro Koskinen <aaro.koskinen at iki dot fi> ---
Ok, such programs can be considered broken.

I was also pointed a workaround if you still need to run such:
https://github.com/andikleen/tsx-tools/blob/master/ignore-xend.c

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

[Bug nptl/17561] GLIBC 2.20 results in SIGILL on x86_64 with double pthread_rwlock_unlock()

[andi-bz at firstfloor dot org]

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

Andi Kleen <andi-bz at firstfloor dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andi-bz at firstfloor dot org

--- Comment #3 from Andi Kleen <andi-bz at firstfloor dot org> ---
Yes don't do that as it's undefined.

In theory it would be possible to put a workaround into glibc for it, but it
would make the unlock path slower and so far it was not deemed needed for this
undefined case.

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