Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5141795ybl; Tue, 14 Jan 2020 04:16:27 -0800 (PST) X-Google-Smtp-Source: APXvYqzcE8EHvvniFNsvV9lhp7gBqKuPNytT89WOy7bVcUQ36YNjRtEqxLQ4mIwj6EV3ZWTCL17A X-Received: by 2002:aca:4d4f:: with SMTP id a76mr16920453oib.26.1579004187774; Tue, 14 Jan 2020 04:16:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579004187; cv=none; d=google.com; s=arc-20160816; b=FT/PM1x1tzuIMQhB8XPLKWldTIK5U+F1StCnKrRgmHTg4FXxlgKPiAdkTc9aNtb0e3 gxrNV1TXmrbPX5k9sRKN5i89L4wcFkV+6UH/xvOSwhgbOjLauw8k4SIfmUMf6P3m7Nkj wm+v5ZoczOVNrspvkW9A6t+YauGy3MLWBj+0XiP7W2WKztYejaFYnMxupz0dA6jUurVC xjWdX8PE0FIAPblPQSAdwrFi1r4L6rHRpQJlCCQlKt8TQNuDwXAOALuagkzP1WZcSW7d yDJf41HWqo8W5pLeUUb4lOmh6by9xfD/oQRIPkY8+IJVawSbqCJa1/2huaS9+DtY/lbA aDdQ== 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:from; bh=X/O/zHUPD/tsRJbg2SatlJZWdQIXw3RKHFLF1svFD2g=; b=bhIfVw2jS+dTXjsRnXRMKj9F40m8bqGkaCFxFA2tXO1v0fD3qdZysL5ALthk2QP6cF STNSOG42ril12Cde+GZqoweyo3ecgFhIUZxUYZBcWRnopUvrnEjcv6woDqVCP26aSZTa exMOcqGVSMjtDTjawYNRrmLBhE1AUl2v3hIraRKaFp97QTwvpxfKvoetGpx+b3e5tngo Y3QlHrnzT5gehl9p+N55jX9NrFjn+7EH/G4bB2A7ER8sji/sKEV6EEfcMdjAUoyeJ9ya MaWoVvabfwW1+px2n/K7oxf3nUt71vlTc4Kd3lykB6cY7lt7orKmXQBLu0PLxnYougLo CfGQ== 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 q72si7758314oic.18.2020.01.14.04.16.13; Tue, 14 Jan 2020 04:16:27 -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 S1729503AbgANMPP (ORCPT + 99 others); Tue, 14 Jan 2020 07:15:15 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:42935 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726053AbgANMPO (ORCPT ); Tue, 14 Jan 2020 07:15:14 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1irL6D-0003Yw-Os; Tue, 14 Jan 2020 13:15:09 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 388A1101DEE; Tue, 14 Jan 2020 13:15:09 +0100 (CET) From: Thomas Gleixner To: Ramon Fried , hkallweit1@gmail.com, bhelgaas@google.com, maz@kernel.org, lorenzo.pieralisi@arm.com Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: MSI irqchip configured as IRQCHIP_ONESHOT_SAFE causes spurious IRQs In-Reply-To: References: Date: Tue, 14 Jan 2020 13:15:09 +0100 Message-ID: <87wo9ub5f6.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ramon Fried writes: > While debugging the root cause of spurious IRQ's on my PCIe MSI line it appears > that because of the line: > info->chip->flags |= IRQCHIP_ONESHOT_SAFE; > in pci_msi_create_irq_domain() > > The IRQF_ONESHOT is ignored, especially when requesting IRQ through > pci_request_threaded_irq() where handler is NULL. Which is perfectly fine. > The problem is that the MSI masking now only surrounds the HW handler, > and all additional MSI that occur before the threaded handler is > complete are considered by the note_interrupt() as spurious. Which is not a problem as long as the thread finishes before 100k MSIs arrived on that line. If that happens then there is something really wrong. Either the device fires MSIs like crazy or the threaded handler is stuck somewhere. > Besides the side effect of that, I don't really understand the logic > of not masking the MSI until the threaded handler is complete, > especially when there's no HW handler and only threaded handler. What's wrong with having another interrupt firing while the threaded handler is running? Nothing, really. It actually can be desired because the threaded handler is allowed to sleep. Thanks, tglx