Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751717AbbBPUPq (ORCPT ); Mon, 16 Feb 2015 15:15:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49639 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751076AbbBPUPo (ORCPT ); Mon, 16 Feb 2015 15:15:44 -0500 Date: Mon, 16 Feb 2015 21:13:13 +0100 From: Oleg Nesterov To: Darren Hart , Peter Zijlstra , Thomas Gleixner Cc: Jerome Marchand , Larry Woodman , Mateusz Guzik , linux-kernel@vger.kernel.org, Alexey Kuznetsov , Pavel Emelyanov Subject: [PATCH 0/1] futex: don't spin waiting for PF_EXITING -> PF_EXITPIDONE transition Message-ID: <20150216201313.GA18246@redhat.com> References: <20150202140515.GA26398@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150202140515.GA26398@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1621 Lines: 44 On 02/02, Oleg Nesterov wrote: > > And another question. Lets forget about this ->mm check. I simply can not > understand this > > ret = (p->flags & PF_EXITPIDONE) ? -ESRCH : -EAGAIN > > logic in attach_to_pi_owner(). First of all, why do we need to retry if > PF_EXITING is set but PF_EXITPIDONE is not? Why we can not simply ignore > PF_EXITING and rely on exit_pi_state_list() if PF_EXITPIDONE is not set? > > I must have missed something but this looks buggy, I do not see any > preemption point ^^^^^^^^^^ I meant synchronization point, sorry for confusion. > in this "retry" loop. Suppose that max_cpus=1 and rt_task() > preempts the non-rt PF_EXITING owner. Looks like futex_lock_pi() can spin > forever in this case? (OK, ignoring RT throttling). Finally I forced myself to try to make the 1st patch ;) To remind, we have more problems with robust+pi futexes, this needs another patch(es). Otherwise we could (probably) even kill PF_EXITPIDONE. Peter. I have no idea how to test it (except it obviously fixes the test- case I sent before). IOW: please review. And I still fail to understand why this PF_EXITING logic was added in the first place. So I also have the problem with the changelog, it merely says "don't do this because this is not needed". On top of "check PF_KTHREAD rather than !p->mm to filter out kthreads" but doesn't depend on it. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/