linux-kernel - Re: [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication when device read fails

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:   Fri, 15 Oct 2021 22:35:52 +0530
From:   Naveen Naidu <naveennaidu479@...il.com>
To:     Ray Jui <ray.jui@...adcom.com>
Cc:     bhelgaas@...gle.com,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        "maintainer:BROADCOM IPROC ARM ARCHITECTURE" 
        <bcm-kernel-feedback-list@...adcom.com>,
        "moderated list:BROADCOM IPROC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 06/24] PCI: iproc: Remove redundant error fabrication
 when device read fails

On 15/10, Ray Jui wrote:
> 
> 
> On 10/15/2021 7:38 AM, Naveen Naidu wrote:
> > An MMIO read from a PCI device that doesn't exist or doesn't respond
> > causes a PCI error. There's no real data to return to satisfy the
> > CPU read, so most hardware fabricates ~0 data.
> > 
> > The host controller drivers sets the error response values (~0) and
> > returns an error when faulty hardware read occurs. But the error
> > response value (~0) is already being set in PCI_OP_READ and
> > PCI_USER_READ_CONFIG whenever a read by host controller driver fails.
> > 
> > Thus, it's no longer necessary for the host controller drivers to
> > fabricate any error response.
> > 
> > This helps unify PCI error response checking and make error check
> > consistent and easier to find.
> > 
> > Signed-off-by: Naveen Naidu <naveennaidu479@...il.com>
> > ---
> >  drivers/pci/controller/pcie-iproc.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> > index 30ac5fbefbbf..e3d86416a4fb 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -659,10 +659,8 @@ static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
> >  	void __iomem *addr;
> >  
> >  	addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
> > -	if (!addr) {
> > -		*val = ~0;
> > +	if (!addr)
> >  		return PCIBIOS_DEVICE_NOT_FOUND;
> > -	}
> >  
> >  	*val = readl(addr);
> >  
> > 
> 
> I think it would be helpful if you include us in the review of the PCI
> core code change (pci.h and access.c) so we get the right context to
> review this change at the individual driver level.
>

I apologize for the rookie mistake ^^', I'll see to it from next time 
that I always add proper recepients to the patches so that everyone 
gets enough context.

> The driver change looks fine to me, as long as the change in the core is
> reviewed and approved.
> 

Thank you very much for taking the time to review it.

> Thanks,
> 
> Ray