Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6506014yba; Tue, 14 May 2019 08:39:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqz3FHNwfUg2cXaYkhTtU33bYzJXUFqsd03sSUNMLpJvjLX8dClUKqXhyhzu/lKqRveBqBFK X-Received: by 2002:a65:44cb:: with SMTP id g11mr38946223pgs.193.1557848364827; Tue, 14 May 2019 08:39:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557848364; cv=none; d=google.com; s=arc-20160816; b=ZhMdP+aXjw1+mrZ/ihrZ1q4/0C2g1c+ap7K7UWafW66ke3LprwfCBTvQ9rnJQFE3p8 oIgY2Hz69oLLJPIbhbIsDlukWI7M//3xKqckeGAYPpWoxhVTs0nxGknblBI6MaGrOuiY wHZCvCWrB2vETUfj8rCWNoUXYYdm/TX8Pa75HH+JPiir2cDL+N00ugnBJDI7RL9d4Xgf 899HYj4wT2ApSccHh2gtA855fps9ucv3It+AL6eKwMN+QlIqLD/J4w58UvVs8HcKVeER 9SR2sx6oxtL6L9k67txErdpkhG4DLirdKYPtJwTtuyAAowKOKZw4PsCSmGbrgb6kyev6 rMng== 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=PozqWuY+LwZjVd284R9ueJdagldyT4yX7CpP/Cbczdw=; b=qi/6KslTSGM1wA4YR0POldfm99W+GWJHgYKexYx+W3O2noUBSajLJUEGLQTiM8CjcP +dSIN1MxOWRiuYz89koaHIrt6D/FEwaqJj2bMvg2bHwLGQhJk9+sDyDwiprbm0NSF5SP S3Hnrgl+gFHl6v82eRYwJ2ZzZs+or0PqgJXszdbs1LYrS9uJwJjWWdjvLThwDQXLOhmG +wDn0D0rYBk9z4VfopDp7nBMVEpFHLibkKJ7KeKhiLmgDk04NrWzD1p2i+mSeBhFfoI2 ZUsNFgF8P4aZEm1qmGVZFLZ2H8Pl+oP7BzQOm9h82bnCxFXlggByf/jDz+oqYcKQuSET YOxw== 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 c72si21553395pfb.93.2019.05.14.08.39.10; Tue, 14 May 2019 08:39:24 -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 S1726201AbfENPgx (ORCPT + 99 others); Tue, 14 May 2019 11:36:53 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:34396 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725916AbfENPgx (ORCPT ); Tue, 14 May 2019 11:36:53 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1hQZU0-0005TC-0d; Tue, 14 May 2019 17:36:48 +0200 Date: Tue, 14 May 2019 17:36:47 +0200 From: Sebastian Andrzej Siewior To: Corey Minyard Cc: Peter Zijlstra , minyard@acm.org, linux-rt-users@vger.kernel.org, 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: <20190514153647.wri6ivffbq7r263y@linutronix.de> References: <20190508205728.25557-1-minyard@acm.org> <20190509161925.kul66w54wpjcinuc@linutronix.de> <20190514084356.GJ2589@hirez.programming.kicks-ass.net> <20190514091219.nesriqe7qplk3476@linutronix.de> <20190514121350.GA6050@minyard.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190514121350.GA6050@minyard.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 07:13:50 [-0500], Corey Minyard wrote: > > Corey, would it make any change which waiter is going to be woken up? > > In the application that found this, the wake order probably isn't > relevant. what I expected. > For other applications, I really doubt that very many are using multiple > waiters. If so, this bug would have been reported sooner, I think. most other do either one waiter/waker pair or one waker and multiple waiter. And then reinit_completion() is used for the next round. > As you mention, for RT you would want waiter woken by priority and FIFO > within priority. I don't think POSIX says anything about FIFO within > priority, but that's probably a good idea. That's no longer a simple > wait queue The way it is now is probably closer to that than what Peter > suggested, but not really that close. > > This is heavily used in drivers and fs code, where it probably doesn't > matter. I looked through a few users in mm and kernel, and they had > one waiter or were init/shutdown type things where order is not important. > > So I'm not sure it's important. Why did you bring POSIX into this? This isn't an API exported to userland which would fall into that category. Peter's suggestion for FIFO is that we probably don't want to starve one thread/waiter if it is always enqueued at the end of the list. As you said, in your case it does not matter because (I assume) each waiter is equal and the outcome would be the same. > -corey Sebastian