From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752201AbbB0Jwu (ORCPT <rfc822;w@1wt.eu>);
	Fri, 27 Feb 2015 04:52:50 -0500
Received: from casper.infradead.org ([85.118.1.10]:34085 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751693AbbB0Jws (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 27 Feb 2015 04:52:48 -0500
Date: Fri, 27 Feb 2015 10:52:40 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Darren Hart <darren@dvhart.com>, Thomas Gleixner <tglx@linutronix.de>,
        Jerome Marchand <jmarchan@redhat.com>,
        Larry Woodman <lwoodman@redhat.com>, Mateusz Guzik <mguzik@redhat.com>,
        linux-kernel@vger.kernel.org, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
        Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [PATCH 1/1] futex: don't spin waiting for PF_EXITING ->
 PF_EXITPIDONE transition
Message-ID: <20150227095240.GO5029@twins.programming.kicks-ass.net>
References: <20150202140515.GA26398@redhat.com>
 <20150216201313.GA18246@redhat.com>
 <20150216201336.GB18246@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150216201336.GB18246@redhat.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 16, 2015 at 09:13:36PM +0100, Oleg Nesterov wrote:

> diff --git a/kernel/futex.c b/kernel/futex.c
> index b101381..c1104a8 100644
> +++ b/kernel/futex.c
> @@ -716,11 +716,13 @@ void exit_pi_state_list(struct task_struct *curr)
>  
>  	if (!futex_cmpxchg_enabled)
>  		return;
> +
>  	/*
> +	 * attach_to_pi_owner() can no longer add the new entry. But
> +	 * we have to be careful versus waiters unqueueing themselves.
>  	 */
> +	curr->flags |= PF_EXITPIDONE;
> +
>  	raw_spin_lock_irq(&curr->pi_lock);
>  	while (!list_empty(head)) {
>  

Should we not set PF_EXITPIDONE _inside_ the pi_lock? To properly
serialize against the below check?

> @@ -905,24 +907,12 @@ static int attach_to_pi_owner(u32 uval, union futex_key *key,
>  		return -EPERM;
>  	}
>  
>  	raw_spin_lock_irq(&p->pi_lock);
> +	if (unlikely(p->flags & PF_EXITPIDONE)) {
> +		/* exit_pi_state_list() was already called */
>  		raw_spin_unlock_irq(&p->pi_lock);
>  		put_task_struct(p);
> +		return -ESRCH;
>  	}
>  
>  	/*