This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Rajalakshmi Srinivasaraghavan <raji at linux dot vnet dot ibm dot com>, <libc-alpha at sourceware dot org>
- Cc: <nd at arm dot com>, aaron Sawdey <acsawdey at linux dot vnet dot ibm dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>, Steve Munroe <sjmunroe at us dot ibm dot co>, <carlos at redhat dot com>, <adconrad at ubuntu dot com>, <wschmidt at linux dot vnet dot ibm dot com>
- Date: Wed, 16 Nov 2016 14:07:49 +0000
- Subject: Re: BZ 20822 :powerpc: race condition in __lll_unlock_elision
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <f777eebe-4a7b-87d2-1281-ab605c7fce8b@linux.vnet.ibm.com> <113d3633-4425-4a56-492e-6aab3b75de2d@linaro.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 16/11/16 13:40, Adhemerval Zanella wrote:
> "[...] Thread A unlocks, thread B continues and returns, destroying
> mutex on stack, then gets into another function, thread A writes to
> *adapt_count and corrupts stack. [...]"
>
> It seems *after* thread B destroy the mutex, it was not clear that
> the program just calls 'pthread_mutex_destroy' or if the thread
> deallocates the mutex on the stack (by returning or something else).
> First option should not trigger an invalid access, but second is
> definitively an program error.
>
does not look like a program error to me:
int i=0;
void threadB()
{
pthread_mutex_t m[1];
//...
pthread_mutex_lock(m);
if (i==1) {
pthread_mutex_unlock(m);
pthread_mutex_destroy(m,0); // ok A is done with m
return; // drop stack frame
}
//...
}
void threadA()
{
// get m from thread B
pthread_mutex_lock(m);
i=1;
pthread_mutex_unlock(m);
// no more use of m here
}
this code can corrupt the stack of threadB if pthread_mutex_unlock
in threadA accesses m->adapt_count after m is unlocked.
(same for rwlocks and whatever else may be used with elision.)