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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190918090547.GZ9720@e119886-lin.cambridge.arm.com>
Date:   Wed, 18 Sep 2019 10:05:48 +0100
From:   Andrew Murray <andrew.murray@....com>
To:     Denis Efremov <efremov@...ux.com>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org, netdev@...r.kernel.org,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v3 13/26] e1000: Use PCI_STD_NUM_BARS

On Mon, Sep 16, 2019 at 11:41:45PM +0300, Denis Efremov wrote:
> To iterate through all possible BARs, loop conditions refactored to the
> *number* of BARs "i < PCI_STD_NUM_BARS", instead of the index of the last
> valid BAR "i <= BAR_5". This is more idiomatic C style and allows to avoid
> the fencepost error.
> 
> Cc: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> Cc: "David S. Miller" <davem@...emloft.net>
> Signed-off-by: Denis Efremov <efremov@...ux.com>
> ---
>  drivers/net/ethernet/intel/e1000/e1000.h      | 1 -
>  drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/e1000/e1000.h b/drivers/net/ethernet/intel/e1000/e1000.h
> index c40729b2c184..7fad2f24dcad 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000.h
> +++ b/drivers/net/ethernet/intel/e1000/e1000.h
> @@ -45,7 +45,6 @@
>  
>  #define BAR_0		0
>  #define BAR_1		1
> -#define BAR_5		5

No issue with this patch. However I noticed that at least 5 of the network
drivers have these same definitions, which are identical to the pci_barno enum
of include/linux/pci-epf.h. There are mostly used with pci_ioremap_bar and
pci_resource_** macros. I wonder if this is an indicator that these defintions
should live in the core.

Thanks,

Andrew Murray

>  
>  #define INTEL_E1000_ETHERNET_DEVICE(device_id) {\
>  	PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
> index f703fa58458e..db4fd82036af 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> @@ -977,7 +977,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>  		goto err_ioremap;
>  
>  	if (adapter->need_ioport) {
> -		for (i = BAR_1; i <= BAR_5; i++) {
> +		for (i = BAR_1; i < PCI_STD_NUM_BARS; i++) {
>  			if (pci_resource_len(pdev, i) == 0)
>  				continue;
>  			if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
> -- 
> 2.21.0
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ