From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> To: Keith Busch <keith.busch@intel.com> Cc: Bjorn Helgaas <helgaas@kernel.org>, Linux PCI <linux-pci@vger.kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Sinan Kaya <okaya@kernel.org>, Thomas Tai <thomas.tai@oracle.com>, poza@codeaurora.org, Lukas Wunner <lukas@wunner.de>, Christoph Hellwig <hch@lst.de>, Mika Westerberg <mika.westerberg@linux.intel.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/12] error handling and pciehp maintenance Date: Tue, 6 Nov 2018 17:21:00 +0000 [thread overview] Message-ID: <20181106172100.GA22063@e107981-ln.cambridge.arm.com> (raw) In-Reply-To: <20181106164751.GA6217@localhost.localdomain> On Tue, Nov 06, 2018 at 09:47:52AM -0700, Keith Busch wrote: > On Tue, Nov 06, 2018 at 04:34:08PM +0000, Lorenzo Pieralisi wrote: > > The question is whether we really need to dynamically patch the kernel > > with ftrace to achieve what that patch does. > > > > Furthermore, it would also be good to report what bugs we are actually > > fixing, from what you are writing falling back to the current method if > > !DYNAMIC_FTRACE_WITH_REGS is broken in many ways and I would start with > > fixing the current behaviour with something that does not depend on arch > > features that may not even be implemented. > > There are two problems with the current method: > > 1. It may dereference pci_dev after it was freed > 2. The pci_dev's children inherit its fake pci_bus's ops on > enumeration > > Both result in kernel panic. That's my point, current test module is not robust, I wanted to ask if there is a way to fix it that does not depend on arch features, because if there is a dependency that is not met we are still not fixing the current code, using it as a fallback can still create issues. > The dynamic kernel patch just seemed like a cool way to inject errors > without messing with the driver's structures. But if there's a more > elegant way to do it, I'm all for it. If you have a simple reproducer for the bugs I am happy to help you test it (I can also apply arm64 DYNAMIC_FTRACE_WITH_REGS patches and test that new code path if that's the final direction we are taking). Thanks, Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 00/12] error handling and pciehp maintenance Date: Tue, 6 Nov 2018 17:21:00 +0000 [thread overview] Message-ID: <20181106172100.GA22063@e107981-ln.cambridge.arm.com> (raw) In-Reply-To: <20181106164751.GA6217@localhost.localdomain> On Tue, Nov 06, 2018 at 09:47:52AM -0700, Keith Busch wrote: > On Tue, Nov 06, 2018 at 04:34:08PM +0000, Lorenzo Pieralisi wrote: > > The question is whether we really need to dynamically patch the kernel > > with ftrace to achieve what that patch does. > > > > Furthermore, it would also be good to report what bugs we are actually > > fixing, from what you are writing falling back to the current method if > > !DYNAMIC_FTRACE_WITH_REGS is broken in many ways and I would start with > > fixing the current behaviour with something that does not depend on arch > > features that may not even be implemented. > > There are two problems with the current method: > > 1. It may dereference pci_dev after it was freed > 2. The pci_dev's children inherit its fake pci_bus's ops on > enumeration > > Both result in kernel panic. That's my point, current test module is not robust, I wanted to ask if there is a way to fix it that does not depend on arch features, because if there is a dependency that is not met we are still not fixing the current code, using it as a fallback can still create issues. > The dynamic kernel patch just seemed like a cool way to inject errors > without messing with the driver's structures. But if there's a more > elegant way to do it, I'm all for it. If you have a simple reproducer for the bugs I am happy to help you test it (I can also apply arm64 DYNAMIC_FTRACE_WITH_REGS patches and test that new code path if that's the final direction we are taking). Thanks, Lorenzo
next prev parent reply other threads:[~2018-11-06 17:21 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-18 23:58 [PATCH 00/12] error handling and pciehp maintenance Keith Busch 2018-09-18 23:58 ` [PATCH 01/12] PCI: Set PCI bus accessors to noinline Keith Busch 2018-09-18 23:58 ` [PATCH 02/12] PCI/AER: Covertly inject errors Keith Busch 2018-09-18 23:58 ` [PATCH 03/12] PCI/AER: Reuse existing service device lookup Keith Busch 2018-09-18 23:58 ` [PATCH 04/12] PCI/AER: Abstract AER interrupt handling Keith Busch 2018-09-18 23:58 ` [PATCH 05/12] PCI/AER: Remove dead code Keith Busch 2018-09-18 23:58 ` [PATCH 06/12] PCI/AER: Remove error source from aer struct Keith Busch 2018-09-18 23:58 ` [PATCH 07/12] PCI/AER: Use kfifo for tracking events Keith Busch 2018-09-18 23:58 ` [PATCH 08/12] PCI/AER: Use kfifo helper inserting locked elements Keith Busch 2018-09-18 23:58 ` [PATCH 09/12] PCI/AER: Don't read upstream ports below fatal errors Keith Busch 2018-09-18 23:58 ` [PATCH 10/12] PCI/AER: Use threaded IRQ for bottom half Keith Busch 2018-09-18 23:58 ` [PATCH 11/12] PCI/AER: Use managed resource allocations Keith Busch 2018-09-19 16:29 ` Sinan Kaya 2018-09-19 17:25 ` Keith Busch 2018-09-19 17:36 ` Sinan Kaya 2018-09-25 1:13 ` Benjamin Herrenschmidt 2018-09-25 14:17 ` Keith Busch 2018-09-18 23:58 ` [PATCH 12/12] PCI/pciehp: Use device managed allocations Keith Busch 2018-09-19 15:11 ` Sinan Kaya 2018-09-19 16:17 ` Keith Busch 2018-09-22 18:10 ` Lukas Wunner 2018-09-24 23:43 ` Bjorn Helgaas 2018-09-25 7:13 ` Lukas Wunner 2018-10-04 21:40 ` [PATCH 00/12] error handling and pciehp maintenance Bjorn Helgaas 2018-10-04 22:11 ` Keith Busch 2018-10-05 17:31 ` Bjorn Helgaas 2018-10-05 17:31 ` Bjorn Helgaas 2018-10-08 16:18 ` Keith Busch 2018-10-08 16:18 ` Keith Busch 2018-10-08 17:23 ` Bjorn Helgaas 2018-10-08 17:23 ` Bjorn Helgaas 2018-11-06 16:34 ` Lorenzo Pieralisi 2018-11-06 16:34 ` Lorenzo Pieralisi 2018-11-06 16:47 ` Keith Busch 2018-11-06 16:47 ` Keith Busch 2018-11-06 17:21 ` Lorenzo Pieralisi [this message] 2018-11-06 17:21 ` Lorenzo Pieralisi 2018-11-06 17:26 ` Keith Busch 2018-11-06 17:26 ` Keith Busch 2018-10-09 16:03 ` Will Deacon 2018-10-09 16:03 ` Will Deacon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181106172100.GA22063@e107981-ln.cambridge.arm.com \ --to=lorenzo.pieralisi@arm.com \ --cc=benh@kernel.crashing.org \ --cc=bhelgaas@google.com \ --cc=catalin.marinas@arm.com \ --cc=hch@lst.de \ --cc=helgaas@kernel.org \ --cc=keith.busch@intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=lukas@wunner.de \ --cc=mika.westerberg@linux.intel.com \ --cc=okaya@kernel.org \ --cc=poza@codeaurora.org \ --cc=thomas.tai@oracle.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.