Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp3444464pxb; Mon, 30 Aug 2021 02:17:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzCTsEtO+Puq+jSBbnIZqzdEs/J5rLvaA5vWVlOy6YfVoVsXe12EgoEJ9DJElRM0r9DFOqC X-Received: by 2002:a17:907:d09:: with SMTP id gn9mr24367936ejc.447.1630315037947; Mon, 30 Aug 2021 02:17:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630315037; cv=none; d=google.com; s=arc-20160816; b=HgQw60Nh8/KaHfkAIC6+sw7599RRiHSX+xKONDCyZvoIX12vQVAWqINFxl5jajQmuk 4/F/TeB4lrIXEzPG2kof61ozmSa1wjB4dOWL942mseODU81oOaDNqwEOopKDJywFriP2 Q/tQnqtaXQWykTADGCBvw7WwcTgH4GZHIS/1taoZVbasA4Z70G5bQCkjCPgPOz13b/Br eRXW8IJG8M3zwyR7XBzJavnna1sUsJEtq1cX4BJTBMeFA+9Qdg1+Ld6TabLcqlKo1vTC lGmV6aJHtZrOOsslgaRSGh/hAhz71CK0MJf/IdhyXTUYjAe1NOrjtFOFQSbI/jtaGtYN 56ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ME7Y4XMLkd2ywGoBwxzGUpsqU/l8DEpJzNl4Cx6nTiY=; b=R6SpC56x8WndH48Yaq/aaR5OSV9bDmSFMGqwMGpKy/tRineHKimElpZR0z7ierTFYv Yi37owd6UhPlC9am3Eh7StY0dsFf8/Q+VtWEjS58ppRus6NPWUZLLAV1xKj4PxRY1co7 HzFfXUxrbqsMFhnzZcDP79u820xTpGMOeYfrCtlBHhNJIR/UWnJoQM3Ob5xbvXn9pIQq cC27aEC7W1Cyzi/37rolQxSNDa9e9Vcd5b013f0PO1SfbSCAdmwSoxuYmm1kHm7yscE4 nOAalB7tnCwWGiUlhXH8BZQE6yugS8IeX/18zWt4/ZVYFryU11PtllHV/wkOMlLfP6Jh XSiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="UYD/5OXL"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w11si18310740ede.300.2021.08.30.02.16.54; Mon, 30 Aug 2021 02:17:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="UYD/5OXL"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235341AbhH3JOX (ORCPT + 99 others); Mon, 30 Aug 2021 05:14:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235042AbhH3JOW (ORCPT ); Mon, 30 Aug 2021 05:14:22 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D456C061575 for ; Mon, 30 Aug 2021 02:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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; bh=ME7Y4XMLkd2ywGoBwxzGUpsqU/l8DEpJzNl4Cx6nTiY=; b=UYD/5OXLS5PVjkjsPGVZaPiYHP CbH7xa8SQVxS5bhUZnZbfk3mjkBeRvrAc++p/X5ry8iMhS+fycnq9inZsE/0gLDE4CNUlxr0jhA4c 2598YOZbF+5vLuDxCDXC8eKGagkXeu5v+n7fNixwXpTbcqGXIRSmUu0ETPc/CLR2Enai8LU6JozDd 3jHGV30PtDOklkqoDjaKYWru/ylnngUWiRMGSdxAAT4FD41RhLdWMukyqOXJ38o3L8G2/tOuzKcZj +wsGWn0+sSte+94sATxol+aB4usOUXtD6eihV0jj6iPKCSmJNJn1GUXTW8vnUJFEu536plOUmx2NS G4SHhCzQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKdKv-00HXnP-94; Mon, 30 Aug 2021 09:12:27 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id DA99698186D; Mon, 30 Aug 2021 11:12:12 +0200 (CEST) Date: Mon, 30 Aug 2021 11:12:12 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: LKML , Valentin Schneider , Daniel Bristot de Oliveira , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Ingo Molnar , Mel Gorman , Dietmar Eggemann Subject: Re: [PATCH V2] sched: Prevent balance_push() on remote runqueues Message-ID: <20210830091212.GG4353@worktop.programming.kicks-ass.net> References: <87tujb0yn1.ffs@tglx> <87eeae11cr.ffs@tglx> <87zgt1hdw7.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zgt1hdw7.ffs@tglx> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 28, 2021 at 03:55:52PM +0200, Thomas Gleixner wrote: > sched_setscheduler() and rt_mutex_setprio() invoke the run-queue balance > callback after changing priorities or the scheduling class of a task. The > run-queue for which the callback is invoked can be local or remote. > > That's not a problem for the regular rq::push_work which is serialized with > a busy flag in the run-queue struct, but for the balance_push() work which > is only valid to be invoked on the outgoing CPU that's wrong. It not only > triggers the debug warning, but also leaves the per CPU variable push_work > unprotected, which can result in double enqueues on the stop machine list. > > Remove the warning and validate that the function is invoked on the > outgoing CPU. > > Fixes: ae7927023243 ("sched: Optimize finish_lock_switch()") > Reported-by: Sebastian Siewior > Signed-off-by: Thomas Gleixner Thanks!