Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6493196yba; Tue, 14 May 2019 08:27:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqyhA0wiQ5VEZM5Jb5RySl6kosx2EJQ66X1aIR2OBE2tBvitQlomxaqBfnv6xDsIyj7Byp9D X-Received: by 2002:a17:902:6b03:: with SMTP id o3mr37813821plk.85.1557847636034; Tue, 14 May 2019 08:27:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557847636; cv=none; d=google.com; s=arc-20160816; b=p2ALnNUgAtAb9VJYzkVez02i1dLqz6hCrObALGWyLHwWxCQSosgTneMw2rWZ5U3Xl2 KZwSCmJZI9D/x+F9DpVmp0sENfSUkchkbqx5zFqWsLcLzpEP5G5TBvzNCutkqzchz+JU 5nnAB8uDKVGBARm0P4MfivKFcV81sEmotIxlWg+YED4XXOjaLYdyFG+Oy7nxNl3UegwR OPSObH7kRQEem9mRgxE08F70xWgfKV0biMWBH5tMGsdnIydodPpuPv/rGy430s48tyzn hLx9ji/FgCHQRViKHLtriTWD2q6Jf3UmeqZcdo1OkUr+DlYiKD4gmt9EPrz/Gf3mc9Ap 8UrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=4jkJmIEnedJqwV12fjpV37JzKioKi8GXSQgdsxTV0pA=; b=JcLM7mV/2bAxTPkZEiTjiecGaDIa6iwLi3XJatlc/iURa38wk3TMfg3qBTLbQyXwuJ blU1bmDTjloV3LKXm3OBMjkDjFVsiqetfQBeW8iUI4op4t2qVal4ShbJNE7bRWkpJxlp W/GGy0l7vda0BludmrCx3vbIwnP3B5EKCnNGJxL7Qbw83ZvgZYFEJ9F4Y3fsYi7wtOcE Efk5AabMSy8dhlQa+bJkSG/9Pxfe1JZaC/JAVofvrU1SUi1Ozzw8XQs2ZBp6bH+7+98D 5ie3A58RstDY/hI4amyE/vD6iytqGU5GbCbw5ADF2cTFguHOpA5vnxeHa99ZlencIrGN 39Gw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d126si19123852pgc.46.2019.05.14.08.27.01; Tue, 14 May 2019 08:27:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726496AbfENPZb (ORCPT + 99 others); Tue, 14 May 2019 11:25:31 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:34374 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726449AbfENPZa (ORCPT ); Tue, 14 May 2019 11:25:30 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1hQZIv-0005IH-9z; Tue, 14 May 2019 17:25:21 +0200 Date: Tue, 14 May 2019 17:25:21 +0200 From: Sebastian Andrzej Siewior To: Peter Zijlstra Cc: minyard@acm.org, linux-rt-users@vger.kernel.org, Corey Minyard , linux-kernel@vger.kernel.org, tglx@linutronix.de, Steven Rostedt , Ingo Molnar Subject: Re: [PATCH RT v2] Fix a lockup in wait_for_completion() and friends Message-ID: <20190514152521.2gz6w2bahhgkxav7@linutronix.de> References: <20190508205728.25557-1-minyard@acm.org> <20190509161925.kul66w54wpjcinuc@linutronix.de> <20190514084356.GJ2589@hirez.programming.kicks-ass.net> <20190514091219.nesriqe7qplk3476@linutronix.de> <20190514113538.GL2589@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190514113538.GL2589@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-05-14 13:35:38 [+0200], Peter Zijlstra wrote: > On Tue, May 14, 2019 at 11:12:19AM +0200, Sebastian Andrzej Siewior wrote: > > On 2019-05-14 10:43:56 [+0200], Peter Zijlstra wrote: > > > Now.. that will fix it, but I think it is also wrong. > > > > > > The problem being that it violates FIFO, something that might be more > > > important on -RT than elsewhere. > > > > Wouldn't -RT be more about waking the task with the highest priority > > instead the one that waited the longest? > > Possibly, but that's a far larger patch. Also, even with that > completions do not avoid inversions and thus don't really make nice RT > primitives anyway. See. So it does not really matter if a particular waiter ends up at the end of the queue. Anyway, I don't really think we need this but if you want it, let me add it. What about the other question I had regarding completion_done()? Sebastian