lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171130181819.GD12096@red-moon>
Date:   Thu, 30 Nov 2017 18:18:19 +0000
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Kishon Vijay Abraham I <kishon@...com>
Cc:     Cyrille Pitchen <cyrille.pitchen@...e-electrons.com>,
        bhelgaas@...gle.com, linux-pci@...r.kernel.org,
        adouglas@...ence.com, stelford@...ence.com, dgary@...ence.com,
        kgopi@...ence.com, eandrews@...ence.com,
        thomas.petazzoni@...e-electrons.com, sureshp@...ence.com,
        nsekhar@...com, linux-kernel@...r.kernel.org, robh@...nel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 0/5] PCI: Add support to the Cadence PCIe controller

On Thu, Nov 30, 2017 at 12:43:20PM +0530, Kishon Vijay Abraham I wrote:

[...]

> >> For linux-next, I applied this series on top of Kishon's patch
> >> ("PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent")
> >> otherwise dma_alloc_coherent() fails when called by pci_epf_alloc_space().
> >>
> >> Also, I patched drivers/Makefile rather than drivers/pci/Makefile to make
> >> the drivers/pci/cadence/pcie-cadence-ep.o linked after
> 
> The reason to patch drivers/Makefile should be because pcie-cadence-ep has to
> be compiled even when CONFIG_PCI is not enabled. CONFIG_PCI enables host
> specific features and ENDPOINT shouldn't depend on CONFIG_PCI.
> >> drivers/pci/endpoint/*.o objects, otherwise the built-in pci-cadence-ep
> >> driver would be probed before the PCI endpoint framework would have been
> >> initialized, which results in a kernel crash.
> > 
> > Nice :( - isn't there a way to improve this (ie probe deferral or
> > registering the EPF bus earlier) ?
> > 
> >> I guess this is the reason why the "pci/dwc" line was also put in
> >> drivers/Makefile, right after the "pci/endpoint" line.
> > 
> > Or probably the other way around - see commit 5e8cb4033807
> > 
> > @Kishon, thoughts ?
> 
> Lorenzo, ordering Makefile is one way to initialize EP core before

Makefile ordering is fragile, I do not like relying on it.

> other drivers. the other way is to have PCI EP core have a different
> initcall level..  subsys_initcall??

Yes, registering the bus at eg postcore_initcall() as PCI does should do
(if that's the problem this is solving) but still, the code must not
crash if the ordering is not correct, we have to fix this regardless.

I would appreciate if Cyrille can debug the cause of the kernel crash
so that we can fix it in the longer term.

Thanks,
Lorenzo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ