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=-5.3 required=3.0 tests=BAYES_00, 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 C3392C433ED for ; Wed, 5 May 2021 12:38:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9ABB6608FE for ; Wed, 5 May 2021 12:38:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233452AbhEEMj0 (ORCPT ); Wed, 5 May 2021 08:39:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41310 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232513AbhEEMiw (ORCPT ); Wed, 5 May 2021 08:38:52 -0400 X-Greylist: delayed 98398 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 05 May 2021 05:37:55 PDT Received: from bmailout2.hostsharing.net (bmailout2.hostsharing.net [IPv6:2a01:37:3000::53df:4ef0:0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55F54C06174A for ; Wed, 5 May 2021 05:37:54 -0700 (PDT) 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 "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 3295D2800B6C9; Wed, 5 May 2021 14:37:53 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 1D07588EB8; Wed, 5 May 2021 14:37:53 +0200 (CEST) Date: Wed, 5 May 2021 14:37:53 +0200 From: Lukas Wunner To: Greg KH Cc: Pali =?iso-8859-1?Q?Roh=E1r?= , linux-usb@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Marek =?iso-8859-1?Q?Beh=FAn?= Subject: Re: xhci_pci & PCIe hotplug crash Message-ID: <20210505123753.GA29101@wunner.de> References: <20210505120117.4wpmo6fhvzznf3wv@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 05, 2021 at 02:09:17PM +0200, Greg KH wrote: > On Wed, May 05, 2021 at 02:01:17PM +0200, Pali Rohár wrote: > > [ 72.511899] Internal error: synchronous external abort: 96000210 [#1] SMP [...] > > [ 72.636415] Call trace: > > [ 72.638936] xhci_irq+0x70/0x17b8 > > [ 72.642360] usb_hcd_irq+0x34/0x50 > > [ 72.645876] usb_hcd_pci_remove+0x78/0x138 > > [ 72.650106] xhci_pci_remove+0x6c/0xa8 > > [ 72.653978] pci_device_remove+0x44/0x108 > > [ 72.658122] device_release_driver_internal+0x110/0x1e0 > > [ 72.663521] device_release_driver+0x1c/0x28 > > [ 72.667931] pci_stop_bus_device+0x84/0xc0 > > [ 72.672162] pci_stop_and_remove_bus_device+0x1c/0x30 > > [ 72.677373] pciehp_unconfigure_device+0x98/0xf8 > > [ 72.682138] pciehp_disable_slot+0x60/0x118 > > [ 72.686457] pciehp_handle_presence_or_link_change+0xec/0x3b0 > > [ 72.692386] pciehp_ist+0x170/0x1a0 > > [ 72.695984] irq_thread_fn+0x30/0x90 ^^^^^^^^^^^^^ [...] > > I suspect that issue is in usb_hcd_pci_remove() function which calls > > local_irq_disable()+usb_hcd_irq()+local_irq_enable() functions but do > > not take into care that whole usb_hcd_pci_remove() function may be > > called from interrupt context. > > usb_hcd_pci_remove() should NOT be called from interrupt context. > > What is causing that to happen? Nothing. It's called from an IRQ *thread*, i.e. task context, see above. > > Can you look at this issue if it is really safe to call usb_hcd_irq() > > from interrupt context? Or rather if it is safe to call functions like > > pciehp_disable_slot() or device_release_driver() from interrupt context > > like it can be seen in call trace? > > What is removing devices from an irq? That is wrong, pci hotplug never > used to do that, what recently changed? Nothing changed, the allegation that something is called from interrupt context is wrong. Thanks, Lukas