From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DA81C433F5 for ; Sun, 10 Apr 2022 19:13:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241158AbiDJTPQ (ORCPT ); Sun, 10 Apr 2022 15:15:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232947AbiDJTPO (ORCPT ); Sun, 10 Apr 2022 15:15:14 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92F7D60CFE; Sun, 10 Apr 2022 12:13:02 -0700 (PDT) Date: Sun, 10 Apr 2022 19:12:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649617981; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mGHXjJncvoi9F9WOlrUAjS83FPKbyxCHc9YHBC9NpS0=; b=WoVTjda+vR274+GnZ+rHqXYcdL67sfGLkHmRu5b4qs5LiZDDPomkjnfstQ0N4QgunDy+e0 grBCyDFzA/HbXz0HHUYmACCLKcVjXeSG2jX9K+AUIztsU5m57mn87oEFT1gmh1Nr6mCljk pK2pyYw51c+m/SzfJW9GjEC4JId+fTWeWRUs925/upwyj1WcCSS84xEBSQ0Z5fZj8RNyiE LBp4OIA/7CfdwOkqbqeyEPcttzvLSCApJqhXkYUH2tGQcXB253e28ZTtCqUKHxUOF1llxY 3ICg7BaW4JzQC4xbXvbBWai9ztMDv6L8t603s/BHQw0YiWDsvUleBLLaqpUYNQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649617981; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mGHXjJncvoi9F9WOlrUAjS83FPKbyxCHc9YHBC9NpS0=; b=3QNV/QDIjFMDkTE9JGe14Z8lpG2dRmAVsZ4VLBX0BBwwodOHx4D/BsxEbxUyPbf7mdzjod uX3ppsxRagf7WzBg== From: "tip-bot2 for Marc Zyngier" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: irq/core] genirq: Always limit the affinity to online CPUs Cc: Marc Zyngier , Thomas Gleixner , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20220405185040.206297-3-maz@kernel.org> References: <20220405185040.206297-3-maz@kernel.org> MIME-Version: 1.0 Message-ID: <164961797999.4207.6664692900996135522.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the irq/core branch of tip: Commit-ID: 33de0aa4bae982ed6f7c777f86b5af3e627ac937 Gitweb: https://git.kernel.org/tip/33de0aa4bae982ed6f7c777f86b5af3e627ac937 Author: Marc Zyngier AuthorDate: Tue, 05 Apr 2022 19:50:39 +01:00 Committer: Thomas Gleixner CommitterDate: Sun, 10 Apr 2022 21:06:30 +02:00 genirq: Always limit the affinity to online CPUs When booting with maxcpus= (or even loading a driver while most CPUs are offline), it is pretty easy to observe managed affinities containing a mix of online and offline CPUs being passed to the irqchip driver. This means that the irqchip cannot trust the affinity passed down from the core code, which is a bit annoying and requires (at least in theory) all drivers to implement some sort of affinity narrowing. In order to address this, always limit the cpumask to the set of online CPUs. Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20220405185040.206297-3-maz@kernel.org --- kernel/irq/manage.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index c03f71d..f71ecc1 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -222,11 +222,16 @@ int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask, { struct irq_desc *desc = irq_data_to_desc(data); struct irq_chip *chip = irq_data_get_irq_chip(data); + const struct cpumask *prog_mask; int ret; + static DEFINE_RAW_SPINLOCK(tmp_mask_lock); + static struct cpumask tmp_mask; + if (!chip || !chip->irq_set_affinity) return -EINVAL; + raw_spin_lock(&tmp_mask_lock); /* * If this is a managed interrupt and housekeeping is enabled on * it check whether the requested affinity mask intersects with @@ -248,24 +253,28 @@ int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask, */ if (irqd_affinity_is_managed(data) && housekeeping_enabled(HK_TYPE_MANAGED_IRQ)) { - const struct cpumask *hk_mask, *prog_mask; - - static DEFINE_RAW_SPINLOCK(tmp_mask_lock); - static struct cpumask tmp_mask; + const struct cpumask *hk_mask; hk_mask = housekeeping_cpumask(HK_TYPE_MANAGED_IRQ); - raw_spin_lock(&tmp_mask_lock); cpumask_and(&tmp_mask, mask, hk_mask); if (!cpumask_intersects(&tmp_mask, cpu_online_mask)) prog_mask = mask; else prog_mask = &tmp_mask; - ret = chip->irq_set_affinity(data, prog_mask, force); - raw_spin_unlock(&tmp_mask_lock); } else { - ret = chip->irq_set_affinity(data, mask, force); + prog_mask = mask; } + + /* Make sure we only provide online CPUs to the irqchip */ + cpumask_and(&tmp_mask, prog_mask, cpu_online_mask); + if (!cpumask_empty(&tmp_mask)) + ret = chip->irq_set_affinity(data, &tmp_mask, force); + else + ret = -EINVAL; + + raw_spin_unlock(&tmp_mask_lock); + switch (ret) { case IRQ_SET_MASK_OK: case IRQ_SET_MASK_OK_DONE: