netdev - Re: [PATCH] stmmac: Replace deprecated PCI functions

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: <dfbc4edd2670fc102ba4959d99bb2c5d6bd1d626.camel@redhat.com>
Date: Wed, 12 Feb 2025 19:19:47 +0100
From: Philipp Stanner <pstanner@...hat.com>
To: Andrew Lunn <andrew@...n.ch>, Philipp Stanner <phasta@...nel.org>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>,  Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
 <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,  Maxime Coquelin
 <mcoquelin.stm32@...il.com>, Alexandre Torgue
 <alexandre.torgue@...s.st.com>, Serge Semin <fancer.lancer@...il.com>,
 Huacai Chen <chenhuacai@...nel.org>, Yinggang Gu <guyinggang@...ngson.cn>,
 Yanteng Si <si.yanteng@...ux.dev>,  netdev@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com, 
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] stmmac: Replace deprecated PCI functions

On Wed, 2025-02-12 at 19:13 +0100, Andrew Lunn wrote:
> >  	/* Get the base address of device */
> > -	for (i = 0; i < PCI_STD_NUM_BARS; i++) {
> > -		if (pci_resource_len(pdev, i) == 0)
> > -			continue;
> > -		ret = pcim_iomap_regions(pdev, BIT(0),
> > pci_name(pdev));
> > -		if (ret)
> > -			goto err_disable_device;
> > -		break;
> > -	}
> > -
> > -	memset(&res, 0, sizeof(res));
> > -	res.addr = pcim_iomap_table(pdev)[0];
> > +	res.addr = pcim_iomap_region(pdev, 0, DRIVER_NAME);
> 
> I don't know too much about PCI, but this change does not look
> obviously correct to me. Maybe the commit message needs expanding to
> explain why the loop can be thrown away? Also, is that BIT(0)
> actually
> wrong, it should of been BIT(i)? Is that why the loop is pointless
> and
> can be removed? If so, we should be asking the developer of this code
> what are the implications of the bug. Should the loop be kept?

Yes, the reason why the loop is pointless is that it calls BIT(0) for
all runs, instead of BIT(i). This would have caused an error btw if it
weren't for pci_resource_len(…) == 0, which I assume prevents trying to
request BAR0 more than once, which s hould fail.

The commit message should mention this, agreed.

I assume this is not a bug, but the code was just copied from the other
part (also touched in this patch) where a loop was necessary. Argument
being that if the above were a bug, it would definitely have been
noticed because the BARs other than 0 are not being mapped, so trying
to access them should result in faults.

Although a confirmation by the respective developer would indeed be
nice.

P.

> 
> 	Andrew