Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6134019yba; Tue, 14 May 2019 02:13:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqy4S4nX5PekGUyxfQjuBAETJ2546pZSg6aQSt//qpA92kwCrHH8Y6bFUKnYJ1D1Nw0WWVYD X-Received: by 2002:a62:7610:: with SMTP id r16mr39413556pfc.69.1557825230276; Tue, 14 May 2019 02:13:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557825230; cv=none; d=google.com; s=arc-20160816; b=DWbQc64RHxMnxn/mY0ecv7Ybb1PjU8ITYS/8IhGE6O7ZnoBMXsYpp1PKnWE7gkupDh 7sNYteMfL64IccIPx6VZAr6RX4bVPvUYxMecuY3gCprfZ6GZ4oiknjhrM5WcxrKPBHA4 C0Win14SwxhY6WbYUk+fJzuSPdhD7e62Npi6QZZUncvxCro2biF2BpaCOQT37rsMHA+9 lMG0SwSm6hS+3RXG+5N05JmnQNlfJXCPmoPSKDSy7xI2OlJcSN6FawU7uXqHOKUwNaLQ pgA6/d+w3X2SuvCBbE7EBFHVxv9wCE+Czz6Z71bXvNOgFio/bkmffR/frb3m9v/qheoi dVPg== 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=Q7efYwDKLUxGbVjfiVpewmmPkm9LNIDaz6WLaiZnRKg=; b=C2lVE8JYjbe/pa/ycW6OUfC1FRQMM3rDdfyfgz6d8zFtp69nb2y7AlJpkjnXjEgMxe QvMZrUP1TWl0K5DlqZQrhQ6D5RPr6hMbGtDvPRbqJeh1d+mPDjbbK2/kdT40Ge0iUZht RJCGxRadpHmxDdc1sQAcAq3KlUZYBNKwLu1GZzS4yVstWXUKZKJbw7AUhsWERZaNWLZy IzVmkt9IwLuE/2dvgUM0mkQsvlTPG6QBo//jPkEjBAESGYsY1rO2iaDrB226XtIfFBZ1 SVtxVkCdL4uSgauj1vcqC60Z9nztzhb4hqgfnnPcC+6Lz1Vxt2FX3JeqxtcIiaJxCH60 LdcQ== 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 n6si4119815pla.380.2019.05.14.02.13.35; Tue, 14 May 2019 02:13:50 -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 S1726409AbfENJM1 (ORCPT + 99 others); Tue, 14 May 2019 05:12:27 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:33246 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725916AbfENJM0 (ORCPT ); Tue, 14 May 2019 05:12:26 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1hQTTv-00074b-Ee; Tue, 14 May 2019 11:12:19 +0200 Date: Tue, 14 May 2019 11:12:19 +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: <20190514091219.nesriqe7qplk3476@linutronix.de> References: <20190508205728.25557-1-minyard@acm.org> <20190509161925.kul66w54wpjcinuc@linutronix.de> <20190514084356.GJ2589@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190514084356.GJ2589@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 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? > The regular wait API seems confused/inconsistent when it uses > autoremove_wake_function and default_wake_function, which doesn't help, > but we can easily support this with swait -- the problematic thing is > the custom wake functions, we musn't do that. > > (also, mingo went and renamed a whole bunch of wait_* crap and didn't do > the same to swait_ so now its named all different :/) > > Something like the below perhaps. This still violates FIFO because a task can do wait_for_completion(), not enqueue itself on the list because it noticed a pending wake and leave. The list order is preserved, we have that. But this a completion list. We have probably multiple worker waiting for something to do so all of those should be of equal priority, maybe one for each core or so. So it shouldn't matter which one we wake up. Corey, would it make any change which waiter is going to be woken up? Sebastian