Re: [PATCH -v5 07/14] futex: Change locking rules

[Thomas Gleixner]

On Sat, 4 Mar 2017, Peter Zijlstra wrote:
> @@ -2166,36 +2252,43 @@ static int fixup_pi_state_owner(u32 __us
>  	/*
> -	 * To handle the page fault we need to drop the hash bucket
> -	 * lock here. That gives the other task (either the highest priority
> -	 * waiter itself or the task which stole the rtmutex) the
> -	 * chance to try the fixup of the pi_state. So once we are
> -	 * back from handling the fault we need to check the pi_state
> -	 * after reacquiring the hash bucket lock and before trying to
> -	 * do another fixup. When the fixup has been done already we
> -	 * simply return.
> +	 * To handle the page fault we need to drop the locks here. That gives
> +	 * the other task (either the highest priority waiter itself or the
> +	 * task which stole the rtmutex) the chance to try the fixup of the
> +	 * pi_state. So once we are back from handling the fault we need to
> +	 * check the pi_state after reacquiring the locks and before trying to
> +	 * do another fixup. When the fixup has been done already we simply
> +	 * return.
> +	 *
> +	 * Note: we hold both hb->lock and pi_mutex->wait_lock. We can safely
> +	 * drop hb->lock since the caller owns the hb -> futex_q relation.
> +	 * Dropping the pi_mutex->wait_lock requires the state revalidate.
>  	 */
>  handle_fault:
> +	raw_spin_unlock_irq(&pi_state->pi_mutex.wait_lock);
>  	spin_unlock(q->lock_ptr);
>  
>  	ret = fault_in_user_writeable(uaddr);
>  
>  	spin_lock(q->lock_ptr);
> +	raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
>  
>  	/*
>  	 * Check if someone else fixed it for us:

Adding context:

         */
        if (pi_state->owner != oldowner)
                return 0;

        if (ret)
                return ret;

        goto retry;

Both 'return' statements leak &pi_state->pi_mutex.wait_lock ....

Thanks,

	tglx