From mboxrd@z Thu Jan 1 00:00:00 1970 From: robin.murphy@arm.com (Robin Murphy) Date: Fri, 27 Jan 2017 18:19:51 +0000 Subject: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling In-Reply-To: <009901d278c7$34fee230$9efca690$@codeaurora.org> References: <1485188293-20263-1-git-send-email-sricharan@codeaurora.org> <1485188293-20263-2-git-send-email-sricharan@codeaurora.org> <4388779a-0e83-fadc-83f4-98c46c88d42e@semihalf.com> <009901d278c7$34fee230$9efca690$@codeaurora.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 27/01/17 18:00, Sricharan wrote: > Hi Robin, > > [..] > >>>> +const struct iommu_ops *of_iommu_configure(struct device *dev, >>>> + struct device_node *master_np) >>>> +{ >>>> + const struct iommu_ops *ops; >>>> + >>>> + if (!master_np) >>>> + return NULL; >>>> + >>>> + if (dev_is_pci(dev)) >>>> + ops = of_pci_iommu_init(to_pci_dev(dev), master_np); >>> >>> I gave the whole patch set a try on ThunderX. really_probe() is failing >>> on dma_configure()->of_pci_iommu_init() for each PCI device. >> >> When you say "failing", do you mean cleanly, or with a crash? I've >> managed to hit __of_match_node() dereferencing NULL from >> of_iommu_xlate() in a horribly complicated chain of events, which I'm >> trying to figure out now, and I wonder if the two might be related. > > Sorry that there is crash still. __of_match_node seems to checking > for NULL arguments , feels like some invalid pointer was passed in. > Is there any particular sequence to try for this ? Ah, I did figure it out - it wasn't actually a NULL dereference, but an unmapped address. Turns out __iommu_of_table is in initdata, so any driver probing after init, connected to an unprobed IOMMU (in this case disabled in DT), trips over trying to match the now-freed table. I'm working on the fix - technically the bug's in my patch (#2) anyway ;) Robin. > > Regards, > Sricharan > > > >