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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA7E4C352A4 for ; Sun, 9 Feb 2020 13:08:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A15AE20714 for ; Sun, 9 Feb 2020 13:08:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727767AbgBINIe (ORCPT ); Sun, 9 Feb 2020 08:08:34 -0500 Received: from bmailout2.hostsharing.net ([83.223.78.240]:57277 "EHLO bmailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727682AbgBINId (ORCPT ); Sun, 9 Feb 2020 08:08:33 -0500 Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 977BB2800A29A; Sun, 9 Feb 2020 14:08:31 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 5C2C5DA4BE; Sun, 9 Feb 2020 14:08:31 +0100 (CET) Date: Sun, 9 Feb 2020 14:08:31 +0100 From: Lukas Wunner To: Stuart Hayes Cc: Bjorn Helgaas , Austin Bolen , keith.busch@intel.com, Alexandru Gagniuc , "Rafael J . Wysocki" , Mika Westerberg , Andy Shevchenko , "Gustavo A . R . Silva" , Sinan Kaya , Oza Pawandeep , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Enzo Matsumiya , kbusch@kernel.org Subject: Re: [PATCH v2] PCI: pciehp: Make sure pciehp_isr clears interrupt events Message-ID: <20200209130831.lfrfylascfzh4d4y@wunner.de> References: <20200129005151.GA247355@google.com> <97162f37-9cde-d349-52e0-c1aaa70ec7a9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97162f37-9cde-d349-52e0-c1aaa70ec7a9@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 29, 2020 at 03:55:21PM -0600, Stuart Hayes wrote: > On 1/28/20 6:51 PM, Bjorn Helgaas wrote: > > I don't understand this limit of six. We clear a status bit above, > > but what's to prevent that same bit from being set again after we read > > it but before we write it? > > I think the nature of the status bits (power fault, link active, etc) > means that they shouldn't be toggling at a high frequency, and there are > only six status bits that can cause this interrupt, which is why I chose > six. But it is really just an arbitrary number that should be larger > than any non-broken system would ever get to, just to safeguard against > getting stuck in the ISR. >From v4.9 until v4.18 we already had a loop which did what you're trying to achieve here. It was added by commit fad214b0aa72 ("PCI: pciehp: Process all hotplug events before looking for new ones"). v4.9 is an LTS stable kernel, it's being used a lot and noone ever complained about the ISR getting stuck. So it seems safe to me to drop the limit of six. It can be added later if issues do get reported. I'm sorry that I dropped the loop when refactoring the code for v4.19. The commit message made it seem that the loop was necessary because we might otherwise miss events. However my refactoring made the code *cope* with missed events, so the loop seemed unnecessary. I didn't realize that the loop is also necessary to avoid missing *interrupts* in the MSI case. Thanks, Lukas