Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752025Ab3JYFNW (ORCPT ); Fri, 25 Oct 2013 01:13:22 -0400 Received: from mail-ie0-f182.google.com ([209.85.223.182]:35236 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751369Ab3JYFNU (ORCPT ); Fri, 25 Oct 2013 01:13:20 -0400 MIME-Version: 1.0 In-Reply-To: References: <20131015024452.GA31951@srcf.ucam.org> <20131016202123.GA17866@google.com> Date: Thu, 24 Oct 2013 22:13:18 -0700 X-Google-Sender-Auth: xd0kflVOzJjJkl3kZbPjBQBx73Q Message-ID: Subject: Re: [3.11.4] Thunderbolt/PCI unplug oops in pci_pme_list_scan From: Yinghai Lu To: Bjorn Helgaas Cc: Andreas Noever , Matthew Garrett , "linux-kernel@vger.kernel.org" , "Rafael J. Wysocki" , "linux-pci@vger.kernel.org" , Mika Westerberg , "Kirill A. Shutemov" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2635 Lines: 68 On Thu, Oct 24, 2013 at 8:33 PM, Bjorn Helgaas wrote: > >>>> Bisection points to 928bea964827d7824b548c1f8e06eccbbc4d0d7d . >>> >>> This is "PCI: Delay enabling bridges until they're needed" by Yinghai. >> >> that double disabling should be addressed by: >> >> https://lkml.org/lkml/2013/4/25/608 >> >> [PATCH] PCI: Remove duplicate pci_disable_device for pcie port > > I'll look at that patch again. I had some questions about it the > first time, but perhaps it makes more sense after 928bea9648 has been > applied. > > Andreas originally reported a GPF oops in pci_pme_list_scan(). I > posted a refcounting patch, which made the problem go away, but I > can't explain why, and I don't want to apply it without understanding > that. Decoding his oops shows this: > > 24: 0f 1f 00 nopl (%rax) > 27: 48 8b 50 10 mov 0x10(%rax),%rdx > 2b:* 48 8b 52 38 mov 0x38(%rdx),%rdx <-- trapping instruction > 2f: 48 85 d2 test %rdx,%rdx > > %rax is the pci_dev pointer, so 0x10(%rax) is the dev->bus pointer, > which we put in %rdx. The oops says %rdx = 6b6b6b6b6b6b6b6b, which is > POISON_FREE, so I think we loaded dev->bus out of a struct pci_dev > that has already been freed. > > pci_pme_list_scan() holds pci_pme_list_mutex while it traverses > pci_pme_list, and the pci_stop_and_remove_bus_device() path removes > the pci_dev by calling pci_pme_active(), which also holds > pci_pme_list_mutex, so I don't understand how pci_pme_list_scan() can > see a pci_dev that has already been freed. > > If I understand Andreas correctly, 928bea9648 also fixes the crash, > even without my refcounting change. Can you explain why? 928bea will make the dev->enable_cnt increase wrongly, as we have pci_enable_device for child pci_enable_bridge for parent pci_enable_bridge for grandparent pci_enable_device for grandparent pci_enable_device for parent pci_enable_brdige for grandparent pci_enable_device for grandparent. ... in that case grandprent will be enabled two times, and will enable_cnt will have extra increase. so later pci_disable_device will not really call do_pci_disable_device do the really work, as enable_cnt still big. solution could be: let pci_enable_bridge call __pci_enable_device. and __pci_enable_device will not call pci_enable_bridge. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/