Re: New Defects reported by Coverity Scan for Linux

Re: New Defects reported by Coverity Scan for Linux

[Bjorn Helgaas]

FYI.  Looks like we rely directy on the result of a read from the
device to index an array, probably not a great idea.

On Mon, Jun 21, 2021 at 07:45:30AM +0000, scan-admin@coverity.com wrote:
> Hi,
> 
> Please find the latest report on new defect(s) introduced to Linux found with Coverity Scan.
> 
> 7 new defect(s) introduced to Linux found with Coverity Scan.
> 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.


> ** CID 1475616:  Memory - illegal accesses  (OVERRUN)
> /drivers/pci/controller/dwc/pcie-tegra194.c: 994 in tegra_pcie_dw_start_link()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 1475616:  Memory - illegal accesses  (OVERRUN)
> /drivers/pci/controller/dwc/pcie-tegra194.c: 994 in tegra_pcie_dw_start_link()
> 988     		retry = false;
> 989     		goto retry_link;
> 990     	}
> 991     
> 992     	speed = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKSTA) &
> 993     		PCI_EXP_LNKSTA_CLS;
> >>>     CID 1475616:  Memory - illegal accesses  (OVERRUN)
> >>>     Overrunning array "pcie_gen_freq" of 4 4-byte elements at element index 4294967295 (byte offset 17179869183) using index "speed - 1U" (which evaluates to 4294967295).
> 994     	clk_set_rate(pcie->core_clk, pcie_gen_freq[speed - 1]);
> 995     
> 996     	tegra_pcie_enable_interrupts(pp);
> 997     
> 998     	return 0;
> 999     }
> 
> ** CID 1475402:  Memory - illegal accesses  (OVERRUN)
> /drivers/pci/controller/dwc/pcie-tegra194.c: 457 in tegra_pcie_ep_irq_thread()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 1475402:  Memory - illegal accesses  (OVERRUN)
> /drivers/pci/controller/dwc/pcie-tegra194.c: 457 in tegra_pcie_ep_irq_thread()
> 451     	struct tegra_pcie_dw *pcie = arg;
> 452     	struct dw_pcie *pci = &pcie->pci;
> 453     	u32 val, speed;
> 454     
> 455     	speed = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKSTA) &
> 456     		PCI_EXP_LNKSTA_CLS;
> >>>     CID 1475402:  Memory - illegal accesses  (OVERRUN)
> >>>     Overrunning array "pcie_gen_freq" of 4 4-byte elements at element index 4294967295 (byte offset 17179869183) using index "speed - 1U" (which evaluates to 4294967295).
> 457     	clk_set_rate(pcie->core_clk, pcie_gen_freq[speed - 1]);
> 458     
> 459     	/* If EP doesn't advertise L1SS, just return */
> 460     	val = dw_pcie_readl_dbi(pci, pcie->cfg_link_cap_l1sub);
> 461     	if (!(val & (PCI_L1SS_CAP_ASPM_L1_1 | PCI_L1SS_CAP_ASPM_L1_2)))
> 462     		return IRQ_HANDLED;

Re: New Defects reported by Coverity Scan for Linux

[Bjorn Helgaas]

[+cc Om, just noticed your series of pcie-tegra194 updates]

On Mon, Jun 21, 2021 at 07:44:26AM -0500, Bjorn Helgaas wrote:
> FYI.  Looks like we rely directy on the result of a read from the
> device to index an array, probably not a great idea.
> 
> On Mon, Jun 21, 2021 at 07:45:30AM +0000, scan-admin@coverity.com wrote:
> > Hi,
> > 
> > Please find the latest report on new defect(s) introduced to Linux found with Coverity Scan.
> > 
> > 7 new defect(s) introduced to Linux found with Coverity Scan.
> > 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
> 
> 
> > ** CID 1475616:  Memory - illegal accesses  (OVERRUN)
> > /drivers/pci/controller/dwc/pcie-tegra194.c: 994 in tegra_pcie_dw_start_link()
> > 
> > 
> > ________________________________________________________________________________________________________
> > *** CID 1475616:  Memory - illegal accesses  (OVERRUN)
> > /drivers/pci/controller/dwc/pcie-tegra194.c: 994 in tegra_pcie_dw_start_link()
> > 988     		retry = false;
> > 989     		goto retry_link;
> > 990     	}
> > 991     
> > 992     	speed = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKSTA) &
> > 993     		PCI_EXP_LNKSTA_CLS;
> > >>>     CID 1475616:  Memory - illegal accesses  (OVERRUN)
> > >>>     Overrunning array "pcie_gen_freq" of 4 4-byte elements at element index 4294967295 (byte offset 17179869183) using index "speed - 1U" (which evaluates to 4294967295).
> > 994     	clk_set_rate(pcie->core_clk, pcie_gen_freq[speed - 1]);
> > 995     
> > 996     	tegra_pcie_enable_interrupts(pp);
> > 997     
> > 998     	return 0;
> > 999     }
> > 
> > ** CID 1475402:  Memory - illegal accesses  (OVERRUN)
> > /drivers/pci/controller/dwc/pcie-tegra194.c: 457 in tegra_pcie_ep_irq_thread()
> > 
> > 
> > ________________________________________________________________________________________________________
> > *** CID 1475402:  Memory - illegal accesses  (OVERRUN)
> > /drivers/pci/controller/dwc/pcie-tegra194.c: 457 in tegra_pcie_ep_irq_thread()
> > 451     	struct tegra_pcie_dw *pcie = arg;
> > 452     	struct dw_pcie *pci = &pcie->pci;
> > 453     	u32 val, speed;
> > 454     
> > 455     	speed = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKSTA) &
> > 456     		PCI_EXP_LNKSTA_CLS;
> > >>>     CID 1475402:  Memory - illegal accesses  (OVERRUN)
> > >>>     Overrunning array "pcie_gen_freq" of 4 4-byte elements at element index 4294967295 (byte offset 17179869183) using index "speed - 1U" (which evaluates to 4294967295).
> > 457     	clk_set_rate(pcie->core_clk, pcie_gen_freq[speed - 1]);
> > 458     
> > 459     	/* If EP doesn't advertise L1SS, just return */
> > 460     	val = dw_pcie_readl_dbi(pci, pcie->cfg_link_cap_l1sub);
> > 461     	if (!(val & (PCI_L1SS_CAP_ASPM_L1_1 | PCI_L1SS_CAP_ASPM_L1_2)))
> > 462     		return IRQ_HANDLED;

Re: New Defects reported by Coverity Scan for Linux

[Om Prakash Singh]

Thanks Bjorn for sharing the result.

We will work on the issue

Thanks,
Om


On 6/21/2021 6:35 PM, Bjorn Helgaas wrote:
> External email: Use caution opening links or attachments
> 
> 
> [+cc Om, just noticed your series of pcie-tegra194 updates]
> 
> On Mon, Jun 21, 2021 at 07:44:26AM -0500, Bjorn Helgaas wrote:
>> FYI.  Looks like we rely directy on the result of a read from the
>> device to index an array, probably not a great idea.
>>
>> On Mon, Jun 21, 2021 at 07:45:30AM +0000, scan-admin@coverity.com wrote:
>>> Hi,
>>>
>>> Please find the latest report on new defect(s) introduced to Linux found with Coverity Scan.
>>>
>>> 7 new defect(s) introduced to Linux found with Coverity Scan.
>>> 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
>>
>>
>>> ** CID 1475616:  Memory - illegal accesses  (OVERRUN)
>>> /drivers/pci/controller/dwc/pcie-tegra194.c: 994 in tegra_pcie_dw_start_link()
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 1475616:  Memory - illegal accesses  (OVERRUN)
>>> /drivers/pci/controller/dwc/pcie-tegra194.c: 994 in tegra_pcie_dw_start_link()
>>> 988                 retry = false;
>>> 989                 goto retry_link;
>>> 990         }
>>> 991
>>> 992         speed = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKSTA) &
>>> 993                 PCI_EXP_LNKSTA_CLS;
>>>>>>      CID 1475616:  Memory - illegal accesses  (OVERRUN)
>>>>>>      Overrunning array "pcie_gen_freq" of 4 4-byte elements at element index 4294967295 (byte offset 17179869183) using index "speed - 1U" (which evaluates to 4294967295).
>>> 994         clk_set_rate(pcie->core_clk, pcie_gen_freq[speed - 1]);
>>> 995
>>> 996         tegra_pcie_enable_interrupts(pp);
>>> 997
>>> 998         return 0;
>>> 999     }
>>>
>>> ** CID 1475402:  Memory - illegal accesses  (OVERRUN)
>>> /drivers/pci/controller/dwc/pcie-tegra194.c: 457 in tegra_pcie_ep_irq_thread()
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 1475402:  Memory - illegal accesses  (OVERRUN)
>>> /drivers/pci/controller/dwc/pcie-tegra194.c: 457 in tegra_pcie_ep_irq_thread()
>>> 451         struct tegra_pcie_dw *pcie = arg;
>>> 452         struct dw_pcie *pci = &pcie->pci;
>>> 453         u32 val, speed;
>>> 454
>>> 455         speed = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKSTA) &
>>> 456                 PCI_EXP_LNKSTA_CLS;
>>>>>>      CID 1475402:  Memory - illegal accesses  (OVERRUN)
>>>>>>      Overrunning array "pcie_gen_freq" of 4 4-byte elements at element index 4294967295 (byte offset 17179869183) using index "speed - 1U" (which evaluates to 4294967295).
>>> 457         clk_set_rate(pcie->core_clk, pcie_gen_freq[speed - 1]);
>>> 458
>>> 459         /* If EP doesn't advertise L1SS, just return */
>>> 460         val = dw_pcie_readl_dbi(pci, pcie->cfg_link_cap_l1sub);
>>> 461         if (!(val & (PCI_L1SS_CAP_ASPM_L1_1 | PCI_L1SS_CAP_ASPM_L1_2)))
>>> 462                 return IRQ_HANDLED;

Re: New Defects reported by Coverity Scan for Linux

[Krzysztof Wilczyński]

[+cc Fabio]

Hi Bjorn, Lorenzo and Rob,

[...]
> > *** CID 1472841:  Error handling issues  (CHECKED_RETURN)
> > /drivers/pci/controller/dwc/pci-exynos.c: 263 in exynos_pcie_host_init()
> > 257     
> > 258     	pp->bridge->ops = &exynos_pci_ops;
> > 259     
> > 260     	exynos_pcie_assert_core_reset(ep);
> > 261     
> > 262     	phy_reset(ep->phy);
> > >>>     CID 1472841:  Error handling issues  (CHECKED_RETURN)
> > >>>     Calling "phy_power_on" without checking return value (as is done elsewhere 40 out of 50 times).
> > 263     	phy_power_on(ep->phy);
> > 264     	phy_init(ep->phy);
> > 265     
> > 266     	exynos_pcie_deassert_core_reset(ep);
> > 267     	exynos_pcie_enable_irq_pulse(ep);
> > 268     

We also have the following defect detected in the same file, and it's of
an identical nature - lack of error checking.  The reported defect:

263        phy_power_on(ep->phy);
CID 1471267 (#1 of 1): Unchecked return value (CHECKED_RETURN)
2. check_return: Calling phy_init without checking return value (as is done elsewhere 41 out of 49 times).
264        phy_init(ep->phy);

This would also be quite trivial to fix, but I don't know much about
Exons, thus I am not sure if there is anything special it would need
aside of perhaps phy_power_off() and phy_exit(), etc.

Krzysztof

Re: New Defects reported by Coverity Scan for Linux

[Bjorn Helgaas]

FYI

On Mon, Feb 08, 2021 at 04:46:46AM +0000, scan-admin@coverity.com wrote:
> 3 new defect(s) introduced to Linux found with Coverity Scan.
> ...

> *** CID 1472841:  Error handling issues  (CHECKED_RETURN)
> /drivers/pci/controller/dwc/pci-exynos.c: 263 in exynos_pcie_host_init()
> 257     
> 258     	pp->bridge->ops = &exynos_pci_ops;
> 259     
> 260     	exynos_pcie_assert_core_reset(ep);
> 261     
> 262     	phy_reset(ep->phy);
> >>>     CID 1472841:  Error handling issues  (CHECKED_RETURN)
> >>>     Calling "phy_power_on" without checking return value (as is done elsewhere 40 out of 50 times).
> 263     	phy_power_on(ep->phy);
> 264     	phy_init(ep->phy);
> 265     
> 266     	exynos_pcie_deassert_core_reset(ep);
> 267     	exynos_pcie_enable_irq_pulse(ep);
> 268     

Re: New Defects reported by Coverity Scan for Linux

[Rob Herring]

On Wed, Nov 11, 2020 at 3:06 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Wed, Nov 11, 2020 at 09:34:10AM -0600, Rob Herring wrote:
> > On Tue, Nov 10, 2020 at 5:36 PM Gustavo Pimentel
> > <Gustavo.Pimentel@synopsys.com> wrote:
> > > On Tue, Nov 10, 2020 at 17:16:41, Bjorn Helgaas <helgaas@kernel.org>
> > > wrote:
> > >
> > > > New Coverity complaint about v5.10-rc3, resulting from 9fff3256f93d
> > > > ("PCI: dwc: Restore ATU memory resource setup to use last entry").
> > > >
> > > > I didn't try to figure out if this is real or a false positive, so
> > > > just FYI.
> > > >
> > > > ----- Forwarded message from scan-admin@coverity.com -----
> > > >
> > > > Date: Mon, 09 Nov 2020 11:13:37 +0000 (UTC)
> > > > From: scan-admin@coverity.com
> > > > To: bjorn@helgaas.com
> > > > Subject: New Defects reported by Coverity Scan for Linux
> > > > Message-ID: <5fa924618fb3b_a62932acac7322f5033088@prd-scan-dashboard-0.mail>
> > > >
> > > > ** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
> > > > /drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()
> > > >
> > > > ________________________________________________________________________________________________________
> > > > *** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
> > > > /drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()
> > > > 590
> > > > 591                   /* Get last memory resource entry */
> > > > 592                   resource_list_for_each_entry(tmp, &pp->bridge->windows)
> > > > 593                           if (resource_type(tmp->res) == IORESOURCE_MEM)
> > >
> > > Can the pp->bridge->windows list be empty in a typical use case?
> >
> > Only if the DT has missing/malformed 'ranges'. 'ranges' is required to
> > have any memory or i/o space, so we would error out before this point.
>
> There are a lot of paths that lead here, and it's an awful lot of work
> to verify that they all correctly error out if 'ranges' is invalid.

There used to be, but I've gotten rid of most. There's also only one
caller of dw_pcie_setup_rc() in the probe path with my latest series
of DWC cleanups that's not applied yet. The only other callers are
from a couple of resume hooks (which I plan to define common functions
for).

The pci_host_bridge allocation/init fails if bridge->windows is not
populated. But actually, 'windows' can never be NULL as it is a
list_head. So it's pp or pp->bridge being NULL that's the complaint,
but that doesn't really change things. The flow is like this:

dw_pcie_host_init()
    -> devm_pci_alloc_host_bridge()
    pp->bridge = bridge;
    ...
    -> dw_pcie_setup_rc()

> It would really be nice if we could structure this in such a way that
> local analysis could show that we never dereference a null pointer
> here.

I've considered making struct pcie_port and struct pci_host_bridge a
single allocation. I'm not sure that's really worth doing though.

> I wouldn't want to uglify the code unnecessarily, but if a small code
> change could avoid this false positive, I think it might be worth
> doing.

Other than also passing in bridge ptr, not sure. Maybe if it is static
which will happen with a common resume routine. That would just shift
the problem though it would be a bit clearer that we really couldn't
ever get to a resume callback with a NULL.

Rob

Re: New Defects reported by Coverity Scan for Linux

[Bjorn Helgaas]

On Wed, Nov 11, 2020 at 09:34:10AM -0600, Rob Herring wrote:
> On Tue, Nov 10, 2020 at 5:36 PM Gustavo Pimentel
> <Gustavo.Pimentel@synopsys.com> wrote:
> > On Tue, Nov 10, 2020 at 17:16:41, Bjorn Helgaas <helgaas@kernel.org>
> > wrote:
> >
> > > New Coverity complaint about v5.10-rc3, resulting from 9fff3256f93d
> > > ("PCI: dwc: Restore ATU memory resource setup to use last entry").
> > >
> > > I didn't try to figure out if this is real or a false positive, so
> > > just FYI.
> > >
> > > ----- Forwarded message from scan-admin@coverity.com -----
> > >
> > > Date: Mon, 09 Nov 2020 11:13:37 +0000 (UTC)
> > > From: scan-admin@coverity.com
> > > To: bjorn@helgaas.com
> > > Subject: New Defects reported by Coverity Scan for Linux
> > > Message-ID: <5fa924618fb3b_a62932acac7322f5033088@prd-scan-dashboard-0.mail>
> > >
> > > ** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
> > > /drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()
> > >
> > > ________________________________________________________________________________________________________
> > > *** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
> > > /drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()
> > > 590
> > > 591                   /* Get last memory resource entry */
> > > 592                   resource_list_for_each_entry(tmp, &pp->bridge->windows)
> > > 593                           if (resource_type(tmp->res) == IORESOURCE_MEM)
> >
> > Can the pp->bridge->windows list be empty in a typical use case?
> 
> Only if the DT has missing/malformed 'ranges'. 'ranges' is required to
> have any memory or i/o space, so we would error out before this point.

There are a lot of paths that lead here, and it's an awful lot of work
to verify that they all correctly error out if 'ranges' is invalid.

It would really be nice if we could structure this in such a way that
local analysis could show that we never dereference a null pointer
here.

I wouldn't want to uglify the code unnecessarily, but if a small code
change could avoid this false positive, I think it might be worth
doing.

Bjorn

Re: New Defects reported by Coverity Scan for Linux

[Rob Herring]

On Tue, Nov 10, 2020 at 5:36 PM Gustavo Pimentel
<Gustavo.Pimentel@synopsys.com> wrote:
>
> On Tue, Nov 10, 2020 at 17:16:41, Bjorn Helgaas <helgaas@kernel.org>
> wrote:
>
> > New Coverity complaint about v5.10-rc3, resulting from 9fff3256f93d
> > ("PCI: dwc: Restore ATU memory resource setup to use last entry").
> >
> > I didn't try to figure out if this is real or a false positive, so
> > just FYI.
> >
> > ----- Forwarded message from scan-admin@coverity.com -----
> >
> > Date: Mon, 09 Nov 2020 11:13:37 +0000 (UTC)
> > From: scan-admin@coverity.com
> > To: bjorn@helgaas.com
> > Subject: New Defects reported by Coverity Scan for Linux
> > Message-ID: <5fa924618fb3b_a62932acac7322f5033088@prd-scan-dashboard-0.mail>
> >
> >
> > ** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
> > /drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()
> >
> >
> > ________________________________________________________________________________________________________
> > *** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
> > /drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()
> > 590
> > 591                   /* Get last memory resource entry */
> > 592                   resource_list_for_each_entry(tmp, &pp->bridge->windows)
> > 593                           if (resource_type(tmp->res) == IORESOURCE_MEM)
>
> Can the pp->bridge->windows list be empty in a typical use case?

Only if the DT has missing/malformed 'ranges'. 'ranges' is required to
have any memory or i/o space, so we would error out before this point.

Rob

RE: New Defects reported by Coverity Scan for Linux

[Gustavo Pimentel]

On Tue, Nov 10, 2020 at 17:16:41, Bjorn Helgaas <helgaas@kernel.org> 
wrote:

> New Coverity complaint about v5.10-rc3, resulting from 9fff3256f93d
> ("PCI: dwc: Restore ATU memory resource setup to use last entry").
> 
> I didn't try to figure out if this is real or a false positive, so
> just FYI.
> 
> ----- Forwarded message from scan-admin@coverity.com -----
> 
> Date: Mon, 09 Nov 2020 11:13:37 +0000 (UTC)
> From: scan-admin@coverity.com
> To: bjorn@helgaas.com
> Subject: New Defects reported by Coverity Scan for Linux
> Message-ID: <5fa924618fb3b_a62932acac7322f5033088@prd-scan-dashboard-0.mail>
> 
> 
> ** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
> /drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
> /drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()
> 590     
> 591     		/* Get last memory resource entry */
> 592     		resource_list_for_each_entry(tmp, &pp->bridge->windows)
> 593     			if (resource_type(tmp->res) == IORESOURCE_MEM)

Can the pp->bridge->windows list be empty in a typical use case?

> 594     				entry = tmp;
> 595     
> >>>     CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
> >>>     Dereferencing null pointer "entry".
> 596     		dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX0,
> 597     					  PCIE_ATU_TYPE_MEM, entry->res->start,
> 598     					  entry->res->start - entry->offset,
> 599     					  resource_size(entry->res));
> 600     		if (pci->num_viewport > 2)
> 601     			dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX2,

New Defects reported by Coverity Scan for Linux

[Bjorn Helgaas]

New Coverity complaint about v5.10-rc3, resulting from 9fff3256f93d
("PCI: dwc: Restore ATU memory resource setup to use last entry").

I didn't try to figure out if this is real or a false positive, so
just FYI.

----- Forwarded message from scan-admin@coverity.com -----

Date: Mon, 09 Nov 2020 11:13:37 +0000 (UTC)
From: scan-admin@coverity.com
To: bjorn@helgaas.com
Subject: New Defects reported by Coverity Scan for Linux
Message-ID: <5fa924618fb3b_a62932acac7322f5033088@prd-scan-dashboard-0.mail>


** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
/drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()


________________________________________________________________________________________________________
*** CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
/drivers/pci/controller/dwc/pcie-designware-host.c: 596 in dw_pcie_setup_rc()
590     
591     		/* Get last memory resource entry */
592     		resource_list_for_each_entry(tmp, &pp->bridge->windows)
593     			if (resource_type(tmp->res) == IORESOURCE_MEM)
594     				entry = tmp;
595     
>>>     CID 1469110:  Null pointer dereferences  (FORWARD_NULL)
>>>     Dereferencing null pointer "entry".
596     		dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX0,
597     					  PCIE_ATU_TYPE_MEM, entry->res->start,
598     					  entry->res->start - entry->offset,
599     					  resource_size(entry->res));
600     		if (pci->num_viewport > 2)
601     			dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX2,