On Nov 18, 2005, at 5:27 AM, Ingo Molnar wrote:
* Dinakar Guniguntala <[email protected]> wrote:
Ingo, Thanks for providing the fix. However I still hit the same bug
even with your changes
even with my patch the robust-futex code is still quite broken. E.g. in
down_futex(), it accesses rt-mutex internals without any locking (!):
if (rt_mutex_free(lock)) {
__down_mutex(lock __EIP__);
rt_mutex_set_owner(lock, owner_task->thread_info);
}
both rt_mutex_free() and rt_mutex_set_owner() must be called with the
proper locking. David?
Yes, the lock needs to be protected by the robust semaphore.
The locking order is:
mmap_sem to protect the vma that holds the pthread_mutex
robust_sem to protect the futex_mutex chain.
futex_mutex - the rt_mutex associated with the
pthread_mutex.
This section of code performs the locking of the first waiter
on the pthread_mutex, which was locked by another thread in the
fast path in userspace. The fast path locking does not enter
the
kernel.
The first waiter locks the futex_mutex and then changes the
owner to the 'owning' thread. The waiter then calls
down_interruptible
to block on the futex_mutex.
I'll provide a patch to protect this piece of code.
David
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
