Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp2087458ybh; Fri, 17 Jul 2020 09:00:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCZowHz6gKc8N9OAHSkXNbRBrtT3OqeXyNR5U+5F92oN7hHhvnmAVj4GalFmoDZkv87VDn X-Received: by 2002:a17:906:ca4c:: with SMTP id jx12mr8553873ejb.231.1595001653753; Fri, 17 Jul 2020 09:00:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595001653; cv=none; d=google.com; s=arc-20160816; b=UWqjWuP4MMMWJ7SPpSbKEuQBkjSXVpMQhgS+FTkNFwKoHeqUOeyQQZcynIU8QvYvmn 0t1VTp9InzI7A2JTg//Zdpb8Noeleqwy3pKMheuYZZYAW2GDQtheKSVVDcQxWlF44bO/ XPMw8Gzbj4Ut+nCipMjnObJsgltp67sBrwwmyZ+EJll2cUW819NkMPcWCLHst05J+PQh 3Few9nq3JiBX13h5zfC1TH7R3NfcSMvShCpnrAH2P/uoZweGjhmwOtL4c7y6W+i4HHKI RZntosOQAY3ZUoXg9ZAd64Wzoqd+wkxGiXyEuvTU8BmQ6tmMzcEqvp42nrHH0u+ZcZqu M+Gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=zzvJduESG71leNpuprS+WOQimkS8tJotSJUZ4FgDv74=; b=SCsgOtklHZRdlHHJkowOSycQoh7GwWUoh27eNcTyS3lFpKTGBFDGPGxzq/9MGtSHH7 3mhzuVQ42zfGFb9ekOe+Lmuen7VAhpUL2poBKy4M8uldEsVWh1o6gGgCF7IyMC2+u1VJ V92/HoyxbXHJPar62/i4cG9Dc9OZzPvDq6vnAZTaidurmm+zYKjFpkYtKUs02rMi0HRE 0BBtmPTNEsSgvxccW67LlIVnmu9LDraqxgneeYsdXmn/HHmIlSRQH+0CURxMPIWMvmU5 9oO1y7AOJ85GriHxFTFaPqP/jXxQlnpBS/YcEXjnv7soe3yZlCFeEtuyUWO3mncu1xZg vXNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=Pt9jOmq5; dkim=neutral (no key) header.i=@vger.kernel.org; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y17si5211489edw.91.2020.07.17.09.00.29; Fri, 17 Jul 2020 09:00:53 -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=@linutronix.de header.s=2020 header.b=Pt9jOmq5; dkim=neutral (no key) header.i=@vger.kernel.org; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726801AbgGQQAH (ORCPT + 99 others); Fri, 17 Jul 2020 12:00:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726381AbgGQQAG (ORCPT ); Fri, 17 Jul 2020 12:00:06 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8341FC0619D2 for ; Fri, 17 Jul 2020 09:00:06 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1595001603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zzvJduESG71leNpuprS+WOQimkS8tJotSJUZ4FgDv74=; b=Pt9jOmq5ExXSqGlkFzHTQErKR0xsRL6t4cAywgJsCx5iVWr+yOEEX7p4xO38U/fIkdTuC7 /lMBvhRk90TPBTo6HYCKFWClqMKT425tN3er680DVBLLk+K9g0K5TxiwxmHbBpEo0m03I0 9aoPHvlhODskjHrH/VHruJJ0zziExMwj+DEWU3OfvnWL27YH89e2AVQllmcGrCN0K0ceMM nqZVN9AfY7VfDVpFzj1mK/FlwsZC4Tm/KBPPyHEyPP4iA93b8l0/RGyTCzHaAhuWqwe+qI LVJ3660GtRk+1a0hB0p95GTNwMsXwvhoalnlZ+ImgIBxtefRq2mPH0pq6q/Utg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1595001603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zzvJduESG71leNpuprS+WOQimkS8tJotSJUZ4FgDv74=; b=03cW4eleU+YLKC/yzkUSSRX0uecOZ2bicPWKgGC4yqlpmknQ9NDokj1e6zWGis/colRvrj 2QqaM61qU+4uDdDQ== To: LKML Cc: x86@kernel.org, Ben Herrenschmidt , Ali Saidi , Marc Zyngier , linux-arm-kernel@lists.infradead.org Subject: [PATCH V2] genirq/affinity: Handle affinity setting on inactive interrupts correctly In-Reply-To: <87k0z2s2q3.fsf@nanos.tec.linutronix.de> References: <87k0z2s2q3.fsf@nanos.tec.linutronix.de> Date: Fri, 17 Jul 2020 18:00:02 +0200 Message-ID: <877dv2rv25.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Setting interrupt affinity on inactive interrupts is inconsistent when hierarchical irq domains are enabled. The core code should just store the affinity and not call into the irq chip driver for inactive interrupts because the chip drivers may not be in a state to handle such requests. X86 has a hacky workaround for that but all other irq chips have not which causes problems e.g. on GIC V3 ITS. Instead of adding more ugly hacks all over the place, solve the problem in the core code. If the affinity is set on an inactive interrupt then: - Store it in the irq descriptors affinity mask - Update the effective affinity to reflect that so user space has a consistent view - Don't call into the irq chip driver This is the core equivalent of the X86 workaround and works correctly because the affinity setting is established in the irq chip when the interrupt is activated later on. Note, that this is only effective when hierarchical irq domains are enabled by the architecture. Doing it unconditionally would break legacy irq chip implementations. For hierarchial irq domains this works correctly as none of the drivers can have a dependency on affinity setting in inactive state by design. Remove the X86 workaround as it is not longer required. Fixes: 02edee152d6e ("x86/apic/vector: Ignore set_affinity call for inactive interrupts") Reported-by: Ali Saidi Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200529015501.15771-1-alisaidi@amazon.com --- V2: Fix the fallout for CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=n (0day) --- arch/x86/kernel/apic/vector.c | 22 +++++----------------- kernel/irq/manage.c | 37 +++++++++++++++++++++++++++++++++++-- 2 files changed, 40 insertions(+), 19 deletions(-) --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -446,12 +446,10 @@ static int x86_vector_activate(struct ir trace_vector_activate(irqd->irq, apicd->is_managed, apicd->can_reserve, reserve); - /* Nothing to do for fixed assigned vectors */ - if (!apicd->can_reserve && !apicd->is_managed) - return 0; - raw_spin_lock_irqsave(&vector_lock, flags); - if (reserve || irqd_is_managed_and_shutdown(irqd)) + if (!apicd->can_reserve && !apicd->is_managed) + assign_irq_vector_any_locked(irqd); + else if (reserve || irqd_is_managed_and_shutdown(irqd)) vector_assign_managed_shutdown(irqd); else if (apicd->is_managed) ret = activate_managed(irqd); @@ -775,20 +773,10 @@ void lapic_offline(void) static int apic_set_affinity(struct irq_data *irqd, const struct cpumask *dest, bool force) { - struct apic_chip_data *apicd = apic_chip_data(irqd); int err; - /* - * Core code can call here for inactive interrupts. For inactive - * interrupts which use managed or reservation mode there is no - * point in going through the vector assignment right now as the - * activation will assign a vector which fits the destination - * cpumask. Let the core code store the destination mask and be - * done with it. - */ - if (!irqd_is_activated(irqd) && - (apicd->is_managed || apicd->can_reserve)) - return IRQ_SET_MASK_OK; + if (WARN_ON_ONCE(!irqd_is_activated(irqd))) + return -EIO; raw_spin_lock(&vector_lock); cpumask_and(vector_searchmask, dest, cpu_online_mask); --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -195,9 +195,9 @@ void irq_set_thread_affinity(struct irq_ set_bit(IRQTF_AFFINITY, &action->thread_flags); } +#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK static void irq_validate_effective_affinity(struct irq_data *data) { -#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK const struct cpumask *m = irq_data_get_effective_affinity_mask(data); struct irq_chip *chip = irq_data_get_irq_chip(data); @@ -205,9 +205,19 @@ static void irq_validate_effective_affin return; pr_warn_once("irq_chip %s did not update eff. affinity mask of irq %u\n", chip->name, data->irq); -#endif } +static inline void irq_init_effective_affinity(struct irq_data *data, + const struct cpumask *mask) +{ + cpumask_copy(irq_data_get_effective_affinity_mask(data), mask); +} +#else +static inline void irq_validate_effective_affinity(struct irq_data *data) { } +static inline void irq_init_effective_affinity(struct irq_data *data, + const struct cpumask *mask) { } +#endif + int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask, bool force) { @@ -304,6 +314,26 @@ static int irq_try_set_affinity(struct i return ret; } +static bool irq_set_affinity_deactivated(struct irq_data *data, + const struct cpumask *mask, bool force) +{ + struct irq_desc *desc = irq_data_to_desc(data); + + /* + * If the interrupt is not yet activated, just store the affinity + * mask and do not call the chip driver at all. On activation the + * driver has to make sure anyway that the interrupt is in a + * useable state so startup works. + */ + if (!IS_ENABLED(CONFIG_IRQ_DOMAIN_HIERARCHY) || irqd_is_activated(data)) + return false; + + cpumask_copy(desc->irq_common_data.affinity, mask); + irq_init_effective_affinity(data, mask); + irqd_set(data, IRQD_AFFINITY_SET); + return true; +} + int irq_set_affinity_locked(struct irq_data *data, const struct cpumask *mask, bool force) { @@ -314,6 +344,9 @@ int irq_set_affinity_locked(struct irq_d if (!chip || !chip->irq_set_affinity) return -EINVAL; + if (irq_set_affinity_deactivated(data, mask, force)) + return 0; + if (irq_can_move_pcntxt(data) && !irqd_is_setaffinity_pending(data)) { ret = irq_try_set_affinity(data, mask, force); } else {