linux-kernel - Re: [PATCH 0/5] PCI: Add support to the Cadence PCIe controller

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]

Date:   Thu, 30 Nov 2017 19:45:16 +0100
From:   Cyrille Pitchen <cyrille.pitchen@...e-electrons.com>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Kishon Vijay Abraham I <kishon@...com>
Cc:     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

Hi all,

Le 30/11/2017 à 19:18, Lorenzo Pieralisi a écrit :
> 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.
> 

I had the crash kernel few weeks ago hence I have to test again to confirm
but if I remember correctly it was a NULL pointer dereferencing crash:

cdns_pcie_ep_probe()
|
+--> devm_pci_epc_create()
     |
     +--> __devm_pci_ep_create()
          |
          +--> __pci_epc_create()
	       |
	       +--> pci_ep_cfs_add_epc_group()
	            |
		    | /*
		    |  * Here controllers_group is still NULL because
		    |  * pci_ep_cfs_init() has not been called yet.
		    |  */
		    +--> configfs_register_group(controllers_group, ...)
		         |
			 +--> link_group()
			      /* Dereferencing NULL pointer */

Best regards,

Cyrille

> Thanks,
> Lorenzo
> 


-- 
Cyrille Pitchen, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com