Received: by 10.223.185.111 with SMTP id b44csp721986wrg; Fri, 9 Mar 2018 12:27:05 -0800 (PST) X-Google-Smtp-Source: AG47ELu45CVP64RJfgB9mP02inoUvrEqq1fBpOCVg0hcBVPh5CrqW+avnFP+aGO+ckNLHDZCokju X-Received: by 10.101.77.201 with SMTP id q9mr25076780pgt.395.1520627225124; Fri, 09 Mar 2018 12:27:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520627225; cv=none; d=google.com; s=arc-20160816; b=zdxyywYozfgPQ8ias+FErB5Q/8Yp8okrP/JDQqWHssBSOzzi+yDQsmizygYabP33qX bXenlsCBeQW45MzivjW7uTOMAyeNgx5MWzNWz7sZw8faDBLpw2PCINLtT4TetQpQNTpo eE2mLyKU8IWUkjtpFPlwSaxp8ojr99S0bQeGo/Z+5ZcSIwI1LLnqh8g8JlYqfhQHYSCq 5JAl5nOCYkJCZ0tGX0ArDjMkokCr2FCFHbJCp/DzK7WCYUj+7227jE25ZVyM7pcnZXg6 EpUWNzGXhWRbuBUZ6bi/k7uAmezfUMWuFzWx62WCA27VRAQWEOOKp0BnQBDQO4k4FIur gMTA== 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:arc-authentication-results; bh=6r/edtaoFze4aUeHVQGuZFmTQjEhks2sIPO/ACV0Y8k=; b=oYa5xbvFc4hAzJGH2ejeY2FP68de/wh5ANxpRg1Fw0haSWjyL0WhSM75VNAol/13L0 DVPugsnFN9ViOV5uu/Caf/qfKBWyO+UQNrjRxd9S+RipnfpjP9GwHqjIR1enDOdCXnyy 58JDx8FPxR4ntYpiSHHQt3q4kRK7K/go90coAs+mUTr5kQBlrmO5RYWv7gCKeAGfKmHv mnVWzXMaxn7VJX+PYyJESuLIJHUgwTD8GQwdCI1qMyJHiyAGLENrEASjRTWUJqbweEOg V64+VHU5b9QL992qwCxF7/JQZQUGuWye3dd033OQYxTt5snkjjA2b4+wSkwsJ9l/Sp/c 0iFw== 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 q11si1199212pgv.138.2018.03.09.12.26.50; Fri, 09 Mar 2018 12:27:05 -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; 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 S932288AbeCIUZ5 (ORCPT + 99 others); Fri, 9 Mar 2018 15:25:57 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:42319 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751192AbeCIUZ4 (ORCPT ); Fri, 9 Mar 2018 15:25:56 -0500 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1euOaM-0006yr-Vr; Fri, 09 Mar 2018 21:25:51 +0100 Date: Fri, 9 Mar 2018 21:25:50 +0100 From: Sebastian Andrzej Siewior To: Peter Zijlstra 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: <20180309202550.j66qphz3txupt55u@linutronix.de> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180309174605.GC4064@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20180223 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-03-09 18:46:05 [+0100], Peter Zijlstra wrote: > On Fri, Mar 09, 2018 at 12:04:18PM +0100, Sebastian Andrzej Siewior wrote: > > +void swake_add_all_wq(struct swait_queue_head *q, struct wake_q_head *wq) > > { > > struct swait_queue *curr; > > > > while (!list_empty(&q->task_list)) { > > > > curr = list_first_entry(&q->task_list, typeof(*curr), > > task_list); > > list_del_init(&curr->task_list); > > + wake_q_add(wq, curr->task); > > } > > } > > +EXPORT_SYMBOL(swake_add_all_wq); > > > > void swake_up(struct swait_queue_head *q) > > { > > @@ -66,25 +62,14 @@ EXPORT_SYMBOL(swake_up); > > */ > > void swake_up_all(struct swait_queue_head *q) > > { > > + unsigned long flags; > > + DEFINE_WAKE_Q(wq); > > > > + raw_spin_lock_irqsave(&q->lock, flags); > > + swake_add_all_wq(q, &wq); > > + raw_spin_unlock_irqrestore(&q->lock, flags); > > > > + wake_up_q(&wq); > > } > > EXPORT_SYMBOL(swake_up_all); > > This is fundamentally wrong. The whole point of wake_up_all() is that > _all_ is unbounded and should not ever land in a single critical > section, be it IRQ or PREEMPT disabled. The above does both. 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. 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. > 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(). 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. > 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. Sebastian