pci: Update VPD size with correct length
PATCH 1/1 pci: Update VPD size with correct length
PCI-2.2 VPD entries have a maximum size of 32k, but might actually be smaller than that. To figure out the actual size one has to read the VPD area until the 'end marker' is reached.
Trying to read VPD data beyond that marker results in 'interesting' effects, from simple read errors to crashing the card. This path modifies the attribute size to the avialable VPD size.
--- drivers/pci/access.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
drivers/pci/access.c +29 -0
@@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)return ret; } +/** +* pci_vpd_size - determine actual size of Vital Product Data +* @dev: pci device struct +* @old_size: current assumed size, also maximum allowed size +* +*/ +size_t +pci_vpd_pci22_size (struct pci_dev *dev,size_t old_size) +{ +loff_t off =0 ; +unsigned char header[1 +2 ];/* 1 byte tag, 2 bytes length */ + +while (off < old_size &&pci_read_vpd (dev, off,1 , header)) { +if (header[0 ] ==0x78 )/* End tag descriptor */ +return off +1 ; +if (header[0 ] &0x80 ) { +/* Large Resource Data Type Tag */ +if (pci_read_vpd (dev, off+1 ,2 , &header[1 ]) !=2 ) +return off +1 ; + off +=3 + ((header[2 ] <<8 ) | header[1 ]); + }else { +/* Short Resource Data Type Tag */ + off +=1 + (header[0 ] &0x07 ); + } + } +return old_size; +} +int pci_vpd_pci22_init (struct pci_dev *dev) {struct pci_vpd_pci22 *vpd;
@@ -436,6 +464,7 @@ int pci_vpd_pci22_init(struct pci_dev *dev) vpd->cap = cap; vpd->busy = false; dev->vpd = &vpd->base; + vpd->base.len =pci_vpd_pci22_size (dev, vpd->base.len);return 0 ; }
Signature · 1 line
1.8.5.6
kbuild test robot
build boturl: https://github.com/0day-ci/linux/commits/Hannes-Reinecke/pci-Update-VPD-size-with-correct-length/20151023-171224 reproduce:
Hi Hannes,
[auto build test WARNING on pci/next -- if it's inappropriate base, please suggest rules for selecting the more suitable base]
url: https://github.com/0day-ci/linux/commits/Hannes-Reinecke/pci-Update-VPD-size-with-correct-length/20151023-171224
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__sparse warnings: (new ones prefixed by >>)
>> drivers/pci/access.c:499:1: sparse: symbol 'pci_vpd_pci22_size' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
kbuild test robot
build bot[RFC PATCH] pci: pci_vpd_pci22_size can be static
In reply to Hannes ReineckeSigned-off-by: Fengguang Wu <[email protected]>
--- access.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/access.c +1 -1
@@ -495,7 +495,7 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)* @old_size: current assumed size, also maximum allowed size * */ -size_t +static size_t pci_vpd_pci22_size (struct pci_dev *dev,size_t old_size) {loff_t off =0 ;
Quoted 38 lines · Hannes Reinecke
PCI-2.2 VPD entries have a maximum size of 32k, but might actually be smaller than that. To figure out the actual size one has to read the VPD area until the 'end marker' is reached.
Trying to read VPD data beyond that marker results in 'interesting' effects, from simple read errors to crashing the card. This path modifies the attribute size to the avialable VPD size.Signed-off-by Hannes Reinecke <[email protected]>--- drivers/pci/access.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)drivers/pci/access.c +18
-0@@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)return ret; } +/** +* pci_vpd_size - determine actual size of Vital Product Data +* @dev: pci device struct +* @old_size: current assumed size, also maximum allowed size +* +*/ +size_t +pci_vpd_pci22_size (struct pci_dev *dev,size_t old_size) +{ +loff_t off =0 ; +unsigned char header[1 +2 ];/* 1 byte tag, 2 bytes length */ + +while (off < old_size &&pci_read_vpd (dev, off,1 , header)) { +if (header[0 ] ==0x78 )/* End tag descriptor */ +return off +1 ; +if (header[0 ] &0x80 ) { +/* Large Resource Data Type Tag */ +if (pci_read_vpd (dev, off+1 ,2 , &header[1 ]) !=2 )
drivers/pci/access.c static int pci_vpd_f0_dev_check(struct pci_dev *dev) · line 439
Quoted 10 lines
drivers/pci/access.c +10
-0+return off +1 ; + off +=3 + ((header[2 ] <<8 ) | header[1 ]); + }else { +/* Short Resource Data Type Tag */ + off +=1 + (header[0 ] &0x07 ); + } + } +return old_size; +} +
My understanding is that the end tag can have some data associated with it such as a checksum. What you may want to look at doing is process long tag and short tag bits first. Then you could do a mask and compare after and if ((header[0] & ~0x7) == 0x78) then you return off + 1.
Also I was wondering if you have looked at the cxgb4 network driver? They are using the vpd read/write calls to access their EEPROM and I assume they are doing so outside the actual VPD fields.
- Alex
Quoted 46 lines · Alexander Duyck
Quoted 45 lines · Hannes Reinecke
PCI-2.2 VPD entries have a maximum size of 32k, but might actually be smaller than that. To figure out the actual size one has to read the VPD area until the 'end marker' is reached.
Trying to read VPD data beyond that marker results in 'interesting' effects, from simple read errors to crashing the card. This path modifies the attribute size to the avialable VPD size.Signed-off-by Hannes Reinecke <[email protected]>--- drivers/pci/access.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)drivers/pci/access.c +25
-0@@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)return ret; } +/** +* pci_vpd_size - determine actual size of Vital Product Data +* @dev: pci device struct +* @old_size: current assumed size, also maximum allowed size +* +*/ +size_t +pci_vpd_pci22_size (struct pci_dev *dev,size_t old_size) +{ +loff_t off =0 ; +unsigned char header[1 +2 ];/* 1 byte tag, 2 bytes length */ + +while (off < old_size &&pci_read_vpd (dev, off,1 , header)) { +if (header[0 ] ==0x78 )/* End tag descriptor */ +return off +1 ; +if (header[0 ] &0x80 ) { +/* Large Resource Data Type Tag */ +if (pci_read_vpd (dev, off+1 ,2 , &header[1 ]) !=2 ) +return off +1 ; + off +=3 + ((header[2 ] <<8 ) | header[1 ]); + }else { +/* Short Resource Data Type Tag */ + off +=1 + (header[0 ] &0x07 ); + } + }
Quoted 9 lines
drivers/pci/access.c static int pci_vpd_f0_dev_check(struct pci_dev *dev) · line 439
Quoted 3 lines
drivers/pci/access.c +3
-0+return old_size; +} +My understanding is that the end tag can have some data associated with it such as a checksum. What you may want to look at doing is process long tag and short tag bits first. Then you could do a mask and compare after and if ((header[0] & ~0x7) ==
0x78) then you return off + 1.
Ah. Oh. Hmm. Wasn't aware of that one.
Bjorn?
Quoted 4 lines
Also I was wondering if you have looked at the cxgb4 network driver? They are using the vpd read/write calls to access their EEPROM and I assume they are doing so outside the actual VPD fields.
As indicated; VPD page access is basically directly wired to the device. So if the vendor chooses to do some extra magic there by all means let him do so. This patch is meant for cards/vendors which (try) to adhere to the PCI VPD specification, so our access to that should be conformant, too.
Cheers,
Hannes
Signature · 4 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
Hi Hannes,
Quoted 56 lines · Hannes Reinecke
Quoted 46 lines · Alexander Duyck
Quoted 45 lines · Hannes Reinecke
PCI-2.2 VPD entries have a maximum size of 32k, but might actually be smaller than that. To figure out the actual size one has to read the VPD area until the 'end marker' is reached.
Trying to read VPD data beyond that marker results in 'interesting' effects, from simple read errors to crashing the card. This path modifies the attribute size to the avialable VPD size.Signed-off-by Hannes Reinecke <[email protected]>--- drivers/pci/access.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)drivers/pci/access.c +25
-0@@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)return ret; } +/** +* pci_vpd_size - determine actual size of Vital Product Data +* @dev: pci device struct +* @old_size: current assumed size, also maximum allowed size +* +*/ +size_t +pci_vpd_pci22_size (struct pci_dev *dev,size_t old_size) +{ +loff_t off =0 ; +unsigned char header[1 +2 ];/* 1 byte tag, 2 bytes length */ + +while (off < old_size &&pci_read_vpd (dev, off,1 , header)) { +if (header[0 ] ==0x78 )/* End tag descriptor */ +return off +1 ; +if (header[0 ] &0x80 ) { +/* Large Resource Data Type Tag */ +if (pci_read_vpd (dev, off+1 ,2 , &header[1 ]) !=2 ) +return off +1 ; + off +=3 + ((header[2 ] <<8 ) | header[1 ]); + }else { +/* Short Resource Data Type Tag */ + off +=1 + (header[0 ] &0x07 ); + } + }Quoted 9 lines
drivers/pci/access.c static int pci_vpd_f0_dev_check(struct pci_dev *dev) · line 439
Quoted 3 lines
drivers/pci/access.c +3
-0+return old_size; +} +My understanding is that the end tag can have some data associated with it such as a checksum. What you may want to look at doing is process long tag and short tag bits first. Then you could do a mask and compare after and if ((header[0] & ~0x7) ==
0x78) then you return off + 1.
Quoted 2 lines
Ah. Oh. Hmm. Wasn't aware of that one.
Bjorn?
I don't know. I took a very quick glance at the PCI 3.0 spec and I didn't see the description of data associated with an End Tag. It'd be nice to have a spec reference for whatever we implement here.
It sounds like this fixes some real problems, and it'd also be nice to have more specifics about them, e.g., what devices, how to reproduce, etc.
Bjorn
Quoted 59 lines · Bjorn Helgaas
Hi Hannes,
Quoted 56 lines · Hannes Reinecke
Quoted 55 lines · Alexander Duyck
Quoted 38 lines · Hannes Reinecke
PCI-2.2 VPD entries have a maximum size of 32k, but might actually be smaller than that. To figure out the actual size one has to read the VPD area until the 'end marker' is reached.
Trying to read VPD data beyond that marker results in 'interesting' effects, from simple read errors to crashing the card. This path modifies the attribute size to the avialable VPD size.Signed-off-by Hannes Reinecke <[email protected]>--- drivers/pci/access.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)drivers/pci/access.c +18
-0@@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)return ret; } +/** +* pci_vpd_size - determine actual size of Vital Product Data +* @dev: pci device struct +* @old_size: current assumed size, also maximum allowed size +* +*/ +size_t +pci_vpd_pci22_size (struct pci_dev *dev,size_t old_size) +{ +loff_t off =0 ; +unsigned char header[1 +2 ];/* 1 byte tag, 2 bytes length */ + +while (off < old_size &&pci_read_vpd (dev, off,1 , header)) { +if (header[0 ] ==0x78 )/* End tag descriptor */ +return off +1 ; +if (header[0 ] &0x80 ) { +/* Large Resource Data Type Tag */ +if (pci_read_vpd (dev, off+1 ,2 , &header[1 ]) !=2 )drivers/pci/access.c static int pci_vpd_f0_dev_check(struct pci_dev *dev) · line 439
Quoted 10 lines
drivers/pci/access.c +10
-0+return off +1 ; + off +=3 + ((header[2 ] <<8 ) | header[1 ]); + }else { +/* Short Resource Data Type Tag */ + off +=1 + (header[0 ] &0x07 ); + } + } +return old_size; +} +My understanding is that the end tag can have some data associated with it such as a checksum. What you may want to look at doing is process long tag and short tag bits first. Then you could do a mask and compare after and if ((header[0] & ~0x7) ==
0x78) then you return off + 1.
Quoted 6 lines
Quoted 2 lines
Ah. Oh. Hmm. Wasn't aware of that one.
Bjorn?I don't know. I took a very quick glance at the PCI 3.0 spec and I didn't see the description of data associated with an End Tag. It'd be nice to have a spec reference for whatever we implement here.
I had originally based my suggestion to include length off an example I saw in the third edition of "PCI System Architecture". However it didn't explain things very well so I did some digging.
The end tag was defined in the Plug and Play ISA Specification, Version 1.0a, section 6.2.2.11. There the end tag supported 1 byte of data for a checksum. I believe the PCI 3.0 spec calls this out as the reference for the small tags and as such we probably should support it.
It is highly likely that there may be implementations that followed the above example and have end tags that may have an additional byte dangling off of them for the checksum. So I would say it is worth it to cover at least that case.
- Alex