Received: by 10.223.185.111 with SMTP id b44csp819188wrg; Fri, 9 Mar 2018 14:28:40 -0800 (PST) X-Google-Smtp-Source: AG47ELv2xV8sUlcXsbInMKhjSoUst32CNux+a42LIpdu0s9z2XTnqCjIB6b11RaLUcupeJwd6cWa X-Received: by 10.101.83.3 with SMTP id m3mr35139pgq.197.1520634520429; Fri, 09 Mar 2018 14:28:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520634520; cv=none; d=google.com; s=arc-20160816; b=eUchMLjkZPwxXuUr5VBGggShexasZD1a/ndkQMFUQGSOIdb1y5TAna1SJJrDm4HPyV fy+Ib5L5bezcNPn/IF+9VUX1aykGDHASAN4B5SlwKac3LhTIEaxUhgxv3JzjmoIIEjmJ XKxSjyKrZYZG9ONCTOr24ydBkBZPud8BoPt6XeKfOmEoQxHb+uHfnDcAHYUrAmKf5CmD 4otCsQDkT59EBaaiPRw4igrpM1ImV1mxnfsb/fdS9XJZFcRCm6OA43Betka5tAce8T2i UD5c/FGE9h7qdJ6kf5kdo83vc3NAc4mp08v3sp9SodyNAAn3FFk+osQVkav24cTlgAVp 1tfA== 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:dkim-signature:arc-authentication-results; bh=qGRdjNuDJo6nBNkFSDT4VaKfBru3bWRjW7yuwrgxhT8=; b=by/yh6VRsdnUsQhuhaSUgYp1QsFvkEpmkZOanY6RUCgY+2Z3kNxHpQju7cEQw9v0Tp 8LDi9SQC7jygCxQIKaqzt6v57sUKMLBPZwXKSw/Ff1WS0IpBHhYSTruFVw4ND42RZ5HV X0YnYEQjGRLk81NRGnNUDtsh0mxCYq9X7TJZcp0XO0pNtXzsy4CC5jfYu+Qs8bxiP1+v mgOcqM5aVHL3VBmilDXSK8wzH8GZ/ZAgE+u+On/fihRFilPUgPrAjGYSxcXk9m18jxcp E3LoHaiGmVJVGhErDmnEYA1ngf8qxeh7VTgQbOgFK+aHKW5YrhlYrSgRWgo9JOimpWek 0prA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=uNZ7g7Fy; 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 d6si1358863pgu.400.2018.03.09.14.28.25; Fri, 09 Mar 2018 14:28:40 -0800 (PST) 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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=uNZ7g7Fy; 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 S933263AbeCIW0z (ORCPT + 99 others); Fri, 9 Mar 2018 17:26:55 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:42336 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932584AbeCIW0x (ORCPT ); Fri, 9 Mar 2018 17:26:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qGRdjNuDJo6nBNkFSDT4VaKfBru3bWRjW7yuwrgxhT8=; b=uNZ7g7Fy+QrcswtA2bIK1oeP2 E6SMRhY7zuvtiUcYHveIyflKTsOC50eQA5P9cmEUu9glUVcgcJ0gg2GBpTC5wBUV1sKlIoVd+niD7 GAPqYXsTrUUUi5RH0J1mf1VcDKkERdrkd6elA13egGbJYx4mjCAyJet6uNFgee0fbF0tc8Evt827q z2oLyixW1omKHnyRqKYN1LSGtf+jd5B0EsrzmB1YbiyUVtlS+aRhwYRoF2ixHgpmE4VXL1M3IQvM6 ZAP+w1nd4WXj5/JdunhlTGhpydDRCprk19rQXE1CVgdoPGPRhgd814eJomtJkh/g3bMeQDzEJqmLt cn492kISQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.89 #1 (Red Hat Linux)) id 1euQTM-00074q-Rz; Fri, 09 Mar 2018 22:26:45 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 24B922029FA14; Fri, 9 Mar 2018 23:26:43 +0100 (CET) Date: Fri, 9 Mar 2018 23:26:43 +0100 From: Peter Zijlstra To: Sebastian Andrzej Siewior Cc: Corey Minyard , Thomas Gleixner , Steven Rostedt , linux-rt-users , linux-kernel , Tejun Heo Subject: Re: Warning from swake_up_all in 4.14.15-rt13 non-RT Message-ID: <20180309222643.GC5926@hirez.programming.kicks-ass.net> References: <20180306174604.nta5rcvfvrfdfftz@linutronix.de> <1704d817-8fb9-ce8f-1aa1-fe6e8b0c3919@mvista.com> <20180308174103.mduy5qq2ttlcvig3@linutronix.de> <20180309110418.lwtennjqwqcxh422@linutronix.de> <20180309174605.GC4064@hirez.programming.kicks-ass.net> <20180309202550.j66qphz3txupt55u@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180309202550.j66qphz3txupt55u@linutronix.de> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 09, 2018 at 09:25:50PM +0100, Sebastian Andrzej Siewior wrote: > Is it just about the irqsave() usage or something else? I doubt it is > the list walk. It is still unbound if not called from irq-off region. The current list walk is preemptible. You put the entire iteration (of unbound length) inside a single critical section which destroy RT. > But it is now possible, I agree. The wake_q usage should be cheaper > compared to IRQ off+on in each loop. And we wanted to do the wake ups > with enabled interrupts - there is still the list_splice() from that > attempt. Now it can be. Unbound is still unbound, inf/n := inf. A 'cheaper' unbound doesn't RT make. > > Yes, wake_up_all() is crap, it is also fundamentally incompatible with > > in-*irq usage. Nothing to be done about that. > I still have (or need) completions which are swait based and do > complete_all(). That's fine, as long as they're done from preemptible context. Back when we introduced swait this was an explicit design goal/limitation. And there were no in-irq users of this. > There are complete_all() caller which wake more than one > waiter (that is PM and crypto from the reports I got once I added the > WARN_ON())). > The in-IRQ usage is !RT only and was there before. Then that's broken and needs to be undone. Also, why did you need the WARN, lockdep should've equally triggered on this, no? > > So NAK on this. > So I need completions to be swait based and do complete_all() from IRQ > (on !RT, not RT). I have this one call which breaks the usage on !RT and > has wake_up_all() in it in vanilla which needs an swait equivalent since > it calls its callback from an rcu-sched section. Why isn't this a problem on RT?