Re: PI BUG with -rt13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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]
  Powered by Linux