Received: by 10.223.176.5 with SMTP id f5csp491054wra; Wed, 7 Feb 2018 02:42:55 -0800 (PST) X-Google-Smtp-Source: AH8x227V5Slob7IGFHXkjWlqy05uTZVlsdK8Up22phHB2NNxcS1nBHdy5IPU6QnrJdU4Vsjm+tKK X-Received: by 10.101.73.143 with SMTP id r15mr4555313pgs.161.1518000175312; Wed, 07 Feb 2018 02:42:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518000175; cv=none; d=google.com; s=arc-20160816; b=XtmcSSFkSEiAC+a2R0i/LZv4c/X32u+VNz/uElAsa8lkZ9fj0Y37SQAhWlTe88Ssll XzwBU/yFfGpet9AQH1qLTkD+D3iyRjBiOPUHggoeD8DMGwhTaEth+s9/h42SuoiMUG2Z U6wPvtsVz4C+zB+BnS0VNROiWDN+IKneLoC3dRQ5ESXz25p/wEyK/RDdO1/pmi/+VTj4 D823HYdhhtQUO9E3qyk2V1BbbydpjMIZ2jY0o39kaJZ6Y12MvXUiRXzTxNeAJgOwfPgj b7BQyuDIeaye2qh0FxhOi3FGkOqMevTn3P8FVQx9jH7iH6qZMjgFmECSxOpI6NcMAqZF hyLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=3UQgzBgbZg5dmypRzf/KeUiFRl0q+5dVFsiCREh5gU4=; b=qmNAc4fYy7REWj1ztim+IV/Uetqa+k4y6f7FZk313dHt6bNbUa7RrznrESjJ7WhMx9 bcB/NfGE/iE2510eoG9o2o0WzjotjFQ/zxxftm3ZwqWSUjAxMKT6vJaRPW0ZHLOzJxWt ZZHEemmx+dcLvXonQNv8Zx7js7SRXtGTOXdp2SJgaZPmn6MIXoQVJyvp5soXLjgClAy+ 3IWLu9n1jdawmXJ5AL8RnIKPBD6BWsFRLvL5GezTIUG/A7b+1PvjJ3h48bBf72U96hwu mMXdcot5pmVOJQL5yEIifFxjmWmXgbdxD3PpDQxgSuaGCjYMCLDIgCy9zMrzp1S504Qg FKqA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b2-v6si911698plk.478.2018.02.07.02.42.41; Wed, 07 Feb 2018 02:42:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932090AbeBGKlX (ORCPT + 99 others); Wed, 7 Feb 2018 05:41:23 -0500 Received: from foss.arm.com ([217.140.101.70]:48852 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753844AbeBGKlV (ORCPT ); Wed, 7 Feb 2018 05:41:21 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0FBAD1435; Wed, 7 Feb 2018 02:41:21 -0800 (PST) Received: from [10.1.207.62] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DFE243F24D; Wed, 7 Feb 2018 02:41:19 -0800 (PST) Subject: Re: [PATCH] irqchip: mips-gic: Avoid spuriously handling masked interrupts To: Matt Redfearn , Thomas Gleixner Cc: linux-mips@linux-mips.org, Ralf Baechle , Jason Cooper , linux-kernel@vger.kernel.org References: <1517849136-29508-1-git-send-email-matt.redfearn@mips.com> From: Marc Zyngier Organization: ARM Ltd Message-ID: <5d6348d6-a87f-d3b7-b758-9a2003d9c50e@arm.com> Date: Wed, 7 Feb 2018 10:41:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/02/18 09:44, Matt Redfearn wrote: > Hi Marc, > > On 07/02/18 09:41, Marc Zyngier wrote: >> On 05/02/18 16:45, Matt Redfearn wrote: >>> Commit 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading >>> GIC_SH_MASK*") removed the read of the hardware mask register when >>> handling shared interrupts, instead using the driver's shadow pcpu_masks >>> entry as the effective mask. Unfortunately this did not take account of >>> the write to pcpu_masks during gic_shared_irq_domain_map, which >>> effectively unmasks the interrupt early. If an interrupt is asserted, >>> gic_handle_shared_int decodes and processes the interrupt even though it >>> has not yet been unmasked via gic_unmask_irq, which also sets the >>> appropriate bit in pcpu_masks. >>> >>> On the MIPS Boston board, when a console command line of >>> "console=ttyS0,115200n8r" is passed, the modem status IRQ is enabled in >>> the UART, which is immediately raised to the GIC. The interrupt has been >>> mapped, but no handler has yet been registered, nor is it expected to be >>> unmasked. However, the write to pcpu_masks in gic_shared_irq_domain_map >>> has effectively unmasked it, resulting in endless reports of: >>> >>> [ 5.058454] irq 13, desc: ffffffff80a7ad80, depth: 1, count: 0, unhandled: 0 >>> [ 5.062057] ->handle_irq(): ffffffff801b1838, >>> [ 5.062175] handle_bad_irq+0x0/0x2c0 >>> >>> Where IRQ 13 is the UART interrupt. >>> >>> To fix this, just remove the write to pcpu_masks in >>> gic_shared_irq_domain_map. The existing write in gic_unmask_irq is the >>> correct place for what is now the effective unmasking. >>> >>> Fixes: 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading GIC_SH_MASK*") >>> Signed-off-by: Matt Redfearn >>> Reviewed-by: Paul Burton >>> >>> --- >>> >>> drivers/irqchip/irq-mips-gic.c | 2 -- >>> 1 file changed, 2 deletions(-) >>> >>> diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c >>> index b2cfc6d66d74..2c3684ba46e5 100644 >>> --- a/drivers/irqchip/irq-mips-gic.c >>> +++ b/drivers/irqchip/irq-mips-gic.c >>> @@ -429,8 +429,6 @@ static int gic_shared_irq_domain_map(struct irq_domain *d, unsigned int virq, >>> spin_lock_irqsave(&gic_lock, flags); >>> write_gic_map_pin(intr, GIC_MAP_PIN_MAP_TO_PIN | shared_cpu_pin); >>> write_gic_map_vp(intr, BIT(mips_cm_vp_id(cpu))); >>> - gic_clear_pcpu_masks(intr); >>> - set_bit(intr, per_cpu_ptr(pcpu_masks, cpu)); >>> irq_data_update_effective_affinity(data, cpumask_of(cpu)); >>> spin_unlock_irqrestore(&gic_lock, flags); >>> >>> >> >> Does this need to be Cc to stable (since it fixes something that was >> merged in 4.14)? > > Sorry, missed stable off the CC list. Yes, it does indeed need to be > backported. Should I resubmit? No need, I'll add that to the patch. Thanks, M. -- Jazz is not dead. It just smells funny...