From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3ED863033E1 for ; Thu, 11 Jun 2026 02:14:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781144096; cv=none; b=eNcm64qnHNl2cFz0o9jJTMC1omzZbAl1JHM+9OuaLmYU3GadPXkROE/bWl5HIwYsFbAUS2SVMezbaaGDrDfhXTSMgN0z5IWvfOq9uFtl05+mWPEKBykUY6I7vtjLbJ6B46qTUKseUrBHjp6GFTLnFWpeDUFFrdvJrF/ARN6S6gc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781144096; c=relaxed/simple; bh=c8KIu8utk6K9+V7DwjcYrWrdHxEZYRI8Qp4Cz4IyI6A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=M5WVa9SQcJB00HUEXO6RprMHieBwbOyurRetSMjnyfDdqq3PmQRMoEfBMO+muNqpJqrivrixu72Snjg4QbgxToszrqk22YWtMA2hKV6tHvWfX8TJC8U160yNssR5mN1r01FhX2NtG1V2+UhzIStpMHZKxKvqYHTnEDjbleqKTz4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=blrZb2Qb; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="blrZb2Qb" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: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=R2YSrL7ixIB7IL2fU25bFDL6XkJgVS+mGH0YSEBeWRU=; b=blrZb2QbD2KBTVlANQ2cfyNbig HcENQRT3zB02WkQNW+tpvsegufuxnCUjt0YCX2EobwXsH5xMl1DqGgLwvn45nMpnRxM39mMSIdBdM lYxQy2vswbrCm9dpSirmlk2OjKSPZLN88exiJAVmMItadvv5zBeSq79iWRdvD4INsWRg4bhsr8qTW R7mnBMB4/VxPfyDaEUbbpzt98FtXi7vIRd93eeAvCXppiHxPq6UQXFp0jSBlocaZmaKLdUfGbvz0E 2/oGYJ3MctcOALrMXSEDcpcYr3pEj54aaH7x4pd8ClEZ89HAderHFAzDCr38rSb5Wmo0p5KGpn6UH aX9aFdhg==; Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1wXUwJ-000000003Zo-0kkZ; Wed, 10 Jun 2026 22:14:39 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: kernel-team@meta.com, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, vschneid@redhat.com, Rik van Riel Subject: [PATCH 7/9] sched/core_sched: defer WARN console output under rq->lock Date: Wed, 10 Jun 2026 22:14:14 -0400 Message-ID: <20260611021416.910555-8-riel@surriel.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260611021416.910555-1-riel@surriel.com> References: <20260611021416.910555-1-riel@surriel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Convert the WARN*() calls that run under rq->lock or ->pi_lock to the SCHED_WARN*() variants, so their console output is deferred to irq_work instead of being emitted synchronously (which can deadlock via console_unlock() -> up(&console_sem) -> try_to_wake_up() while the lock is held). This should prevent a deadlock if these warnings fire with a legacy or boot console configured. Signed-off-by: Rik van Riel Assisted-by: Claude:claude-opus-4-8 --- kernel/sched/core_sched.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/sched/core_sched.c b/kernel/sched/core_sched.c index 43e0bde3038e..e39fb8935ef7 100644 --- a/kernel/sched/core_sched.c +++ b/kernel/sched/core_sched.c @@ -67,7 +67,7 @@ static unsigned long sched_core_update_cookie(struct task_struct *p, * a cookie until after we've removed it, we must have core scheduling * enabled here. */ - WARN_ON_ONCE((p->core_cookie || cookie) && !sched_core_enabled(rq)); + SCHED_WARN_ON_ONCE((p->core_cookie || cookie) && !sched_core_enabled(rq)); if (sched_core_enqueued(p)) sched_core_dequeue(rq, p, DEQUEUE_SAVE); @@ -249,7 +249,7 @@ void __sched_core_account_forceidle(struct rq *rq) lockdep_assert_rq_held(rq); - WARN_ON_ONCE(!rq->core->core_forceidle_count); + SCHED_WARN_ON_ONCE(!rq->core->core_forceidle_count); if (rq->core->core_forceidle_start == 0) return; @@ -260,7 +260,7 @@ void __sched_core_account_forceidle(struct rq *rq) rq->core->core_forceidle_start = now; - if (WARN_ON_ONCE(!rq->core->core_forceidle_occupation)) { + if (SCHED_WARN_ON_ONCE(!rq->core->core_forceidle_occupation)) { /* can't be forced idle without a running task */ } else if (rq->core->core_forceidle_count > 1 || rq->core->core_forceidle_occupation > 1) { -- 2.53.0-Meta