Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3094639rwb; Mon, 15 Aug 2022 18:00:10 -0700 (PDT) X-Google-Smtp-Source: AA6agR5DQCwVDeY8k4QBP63ZZ5PGvA9/yyQB/ljtY1auJ/JsHPuKT0WQ6Scb5D44hr4BNbqf456Y X-Received: by 2002:a17:906:ef8c:b0:730:ebff:9e19 with SMTP id ze12-20020a170906ef8c00b00730ebff9e19mr11936105ejb.300.1660611610272; Mon, 15 Aug 2022 18:00:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660611610; cv=none; d=google.com; s=arc-20160816; b=XegQYFbtCfiKwarVHmaELlyMdXVJF3UcAR83GOQB9ksRZAnpxVoKvJGdQBK7LiSima 1LQ51pxlFDKToPgNAZNGkEINLg/bt3bCYrgSn4fr9mL3zYz2XPfI0R7l8iaXK6oyFE1M Fu4ZzsJjnh0EVhY6iyDJlhXb2bNHal08rXScAGj0XqUQS8zycffySGuQzH6u8oTYaVRN aqR2tHs+lfEU0MbpDMRYOsB4bbrliZmEpRX/Afb6A/iCnwgEWfbjUrRdJAz7458UT3wy AxARMZOOPbdO4lYeEv/CjfaTGVa1l+csqiCDXUkyEG0nxHArdS1nzJK7QQetMMg6oJ0A t1qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=s8qFMeSlFlrARFZXNAYZyr0rYD6cAR7MXXQVKVIaG5s=; b=ldR6gOghrCk3Fze+kiIGEz8ppSREaqJqA6YBCWswa8qG89yGbziGA98AZZCgicyehr hpkvTVZfGX0o1oFGneWKHZnFo5qQ929ICWluS9zoPHW1lcdZlbx1AlhUPwLiOHj17j7k 7fK6qMDV1kLHum9l09hxUfQ8e9RMGR1siLWBMY2/qq5tgjmZiDpU761mUx2T8+lOaHzQ yZLgtXOuqilxajTbQHe+wcJH5zI6d0LlIVz8mze5M1FvqxfgjdTKEmVEMRg9PkHfW+NE RgpJtn7PhqP/1py4o/yEl209zVhd1FXKIxmsodlnmdML4YW7ryRwnmwkAez4T3oE/cg7 QfFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DVxcFtC1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e20-20020a50d4d4000000b0044052e86694si9046022edj.377.2022.08.15.17.59.38; Mon, 15 Aug 2022 18:00:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DVxcFtC1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346717AbiHPAvR (ORCPT + 99 others); Mon, 15 Aug 2022 20:51:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348453AbiHPAqU (ORCPT ); Mon, 15 Aug 2022 20:46:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 02393194E64; Mon, 15 Aug 2022 13:44:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 929ED611E2; Mon, 15 Aug 2022 20:44:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81263C433D6; Mon, 15 Aug 2022 20:44:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660596275; bh=HSYtq/8VlNbrxLv2/e0LpVYwwGCzQZuFENn4nztUwSE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DVxcFtC14MbZHlhDPdfVa0BiLB8i83KqIYwelvbZ45wPtTyJcufdoSYvWRhCNhQ4F 9NYKd6UyjRNsPQ8sgxu5NiGVzenpipFgCwLWXeR+uTadBgjSSe/NWGCwUHjc4YFewq TYC5HMw3ENwhtrnqXyVxVYIEvG309psrVTMSeYbI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mel Gorman , Ingo Molnar , Sasha Levin Subject: [PATCH 5.19 1027/1157] sched/core: Do not requeue task on CPU excluded from cpus_mask Date: Mon, 15 Aug 2022 20:06:23 +0200 Message-Id: <20220815180521.025791014@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220815180439.416659447@linuxfoundation.org> References: <20220815180439.416659447@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mel Gorman [ Upstream commit 751d4cbc43879229dbc124afefe240b70fd29a85 ] The following warning was triggered on a large machine early in boot on a distribution kernel but the same problem should also affect mainline. WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440 Call Trace: rescuer_thread+0x1f6/0x360 kthread+0x156/0x180 ret_from_fork+0x22/0x30 Commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") optimises ttwu by queueing a task that is descheduling on the wakelist, but does not check if the task descheduling is still allowed to run on that CPU. In this warning, the problematic task is a workqueue rescue thread which checks if the rescue is for a per-cpu workqueue and running on the wrong CPU. While this is early in boot and it should be possible to create workers, the rescue thread may still used if the MAYDAY_INITIAL_TIMEOUT is reached or MAYDAY_INTERVAL and on a sufficiently large machine, the rescue thread is being used frequently. Tracing confirmed that the task should have migrated properly using the stopper thread to handle the migration. However, a parallel wakeup from udev running on another CPU that does not share CPU cache observes p->on_cpu and uses task_cpu(p), queues the task on the old CPU and triggers the warning. Check that the wakee task that is descheduling is still allowed to run on its current CPU and if not, wait for the descheduling to complete and select an allowed CPU. Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") Signed-off-by: Mel Gorman Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20220804092119.20137-1-mgorman@techsingularity.net Signed-off-by: Sasha Levin --- kernel/sched/core.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 0066b9d66e25..d4af56927a4d 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3808,7 +3808,7 @@ bool cpus_share_cache(int this_cpu, int that_cpu) return per_cpu(sd_llc_id, this_cpu) == per_cpu(sd_llc_id, that_cpu); } -static inline bool ttwu_queue_cond(int cpu) +static inline bool ttwu_queue_cond(struct task_struct *p, int cpu) { /* * Do not complicate things with the async wake_list while the CPU is @@ -3817,6 +3817,10 @@ static inline bool ttwu_queue_cond(int cpu) if (!cpu_active(cpu)) return false; + /* Ensure the task will still be allowed to run on the CPU. */ + if (!cpumask_test_cpu(cpu, p->cpus_ptr)) + return false; + /* * If the CPU does not share cache, then queue the task on the * remote rqs wakelist to avoid accessing remote data. @@ -3846,7 +3850,7 @@ static inline bool ttwu_queue_cond(int cpu) static bool ttwu_queue_wakelist(struct task_struct *p, int cpu, int wake_flags) { - if (sched_feat(TTWU_QUEUE) && ttwu_queue_cond(cpu)) { + if (sched_feat(TTWU_QUEUE) && ttwu_queue_cond(p, cpu)) { sched_clock_cpu(cpu); /* Sync clocks across CPUs */ __ttwu_queue_wakelist(p, cpu, wake_flags); return true; -- 2.35.1