All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Hannes Reinecke <hare@suse.de>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 1/5] PCI/VPD: Refactor pci_vpd_size
Date: Tue, 13 Jul 2021 23:13:31 +0200	[thread overview]
Message-ID: <0fb70529-3b0e-4865-bf6d-460030948019@gmail.com> (raw)
In-Reply-To: <20210713202555.GA1771351@bjorn-Precision-5520>

On 13.07.2021 22:25, Bjorn Helgaas wrote:
> [+cc Hannes]
> 
> On Thu, May 13, 2021 at 10:58:40PM +0200, Heiner Kallweit wrote:
>> The only Short Resource Data Type tag is the end tag. This allows to
>> remove the generic SRDT tag handling and the code be significantly
>> simplified.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>>  drivers/pci/vpd.c | 46 ++++++++++++----------------------------------
>>  1 file changed, 12 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
>> index 26bf7c877..ecdce170f 100644
>> --- a/drivers/pci/vpd.c
>> +++ b/drivers/pci/vpd.c
>> @@ -73,50 +73,28 @@ EXPORT_SYMBOL(pci_write_vpd);
>>  static size_t pci_vpd_size(struct pci_dev *dev, size_t old_size)
>>  {
>>  	size_t off = 0;
>> -	unsigned char header[1+2];	/* 1 byte tag, 2 bytes length */
>> +	u8 header[3];	/* 1 byte tag, 2 bytes length */
>>  
>>  	while (off < old_size && pci_read_vpd(dev, off, 1, header) == 1) {
>> -		unsigned char tag;
>> -
>>  		if (!header[0] && !off) {
>>  			pci_info(dev, "Invalid VPD tag 00, assume missing optional VPD EPROM\n");
>>  			return 0;
>>  		}
>>  
>> -		if (header[0] & PCI_VPD_LRDT) {
>> -			/* Large Resource Data Type Tag */
>> -			tag = pci_vpd_lrdt_tag(header);
>> -			/* Only read length from known tag items */
>> -			if ((tag == PCI_VPD_LTIN_ID_STRING) ||
>> -			    (tag == PCI_VPD_LTIN_RO_DATA) ||
>> -			    (tag == PCI_VPD_LTIN_RW_DATA)) {
>> -				if (pci_read_vpd(dev, off+1, 2,
>> -						 &header[1]) != 2) {
>> -					pci_warn(dev, "invalid large VPD tag %02x size at offset %zu",
>> -						 tag, off + 1);
>> -					return 0;
>> -				}
>> -				off += PCI_VPD_LRDT_TAG_SIZE +
>> -					pci_vpd_lrdt_size(header);
>> -			}
>> -		} else {
>> -			/* Short Resource Data Type Tag */
>> -			off += PCI_VPD_SRDT_TAG_SIZE +
>> -				pci_vpd_srdt_size(header);
>> -			tag = pci_vpd_srdt_tag(header);
>> -		}
>> -
>> -		if (tag == PCI_VPD_STIN_END)	/* End tag descriptor */
>> -			return off;
>> +		if (header[0] == PCI_VPD_SRDT_END)
>> +			return off + PCI_VPD_SRDT_TAG_SIZE;
> 
> This makes the code beautiful.  But I think pci_vpd_size() is too
> picky even now, and this patch makes it more so.
> 
> I don't know why pci_vpd_size() currently checks the tags for
> ID_STRING, RO_DATA, and RW_DATA.  That seems too aggressive to me.
> 

It checks for these tags (+ the end tag) because it's the only ones
defined for VPD by the PCI spec.

> I think these data items originally came from PNP ISA, and it defines
> several other tags.  Of course, that wasn't for PCI devices, but a
> Google search for '"invalid" "vpd tag" "at offset"' does find several
> cases where VPD contains things that look like PNP ISA data items.
> 

Right, the tag format is based on PNP ISA. But PCI spec explicitly
lists the supported tags.
I tried to do the same search and found:
- "invalid short vpd tag 00" and "invalid large tag 7f"
   Both are symptom of a missing optional VPD EEPROM.
- "ixgbe 0000:0b:00.0: invalid short VPD tag 06 at offset 4" and a
  similar message for igb
  I didn't see any response explaining what causes this issue.
  My personal guess: Some OEM provided invalid VPD EEPROM content.
  Offset 4 is the first character of the ID string. The message
  indicates that the ID tag declares an empty ID. That would be weird.

> I think we should compute the VPD size by iterating through it looking
> only at the type (small or large) and the data item length until we
> find the End Tag.
> 

Still I didn't see any example of a rejected valid VPD image.
Not checking for supported tags increases he risk that we interpret
a random byte as tag and read beyond the VPD end, what is known to
cause a freeze on some devices.

> This code originally came from 104daa71b396 ("PCI: Determine actual
> VPD size on first access"), so I added Hannes in case there was some
> reason we do the extra validation.
> 
>> -		if ((tag != PCI_VPD_LTIN_ID_STRING) &&
>> -		    (tag != PCI_VPD_LTIN_RO_DATA) &&
>> -		    (tag != PCI_VPD_LTIN_RW_DATA)) {
>> -			pci_warn(dev, "invalid %s VPD tag %02x at offset %zu",
>> -				 (header[0] & PCI_VPD_LRDT) ? "large" : "short",
>> -				 tag, off);
>> +		if (header[0] != PCI_VPD_LRDT_ID_STRING &&
>> +		    header[0] != PCI_VPD_LRDT_RO_DATA &&
>> +		    header[0] != PCI_VPD_LRDT_RW_DATA) {
>> +			pci_warn(dev, "invalid VPD tag %02x at offset %zu", header[0], off);
>>  			return 0;
>>  		}
>> +
>> +		if (pci_read_vpd(dev, off + 1, 2, header + 1) != 2)
>> +			return 0;
>> +
>> +		off += PCI_VPD_LRDT_TAG_SIZE + pci_vpd_lrdt_size(header);
>>  	}
>>  	return 0;
>>  }
>> -- 
>> 2.31.1
>>
>>


  reply	other threads:[~2021-07-13 21:13 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13 20:53 [PATCH 0/5] PCI/VPD: Further improvements Heiner Kallweit
2021-05-13 20:55 ` [PATCH 2/5] PCI: Clean up VPD constants and functions in pci.h Heiner Kallweit
2021-07-14 16:43   ` Bjorn Helgaas
2021-05-13 20:56 ` [PATCH 3/5] PCI/VPD: Remove old_size argument from pci_vpd_size Heiner Kallweit
2021-05-13 20:56 ` [PATCH 4/5] PCI/VPD: Make pci_vpd_wait uninterruptible Heiner Kallweit
2021-05-13 20:58 ` [PATCH 1/5] PCI/VPD: Refactor pci_vpd_size Heiner Kallweit
2021-07-13 20:25   ` Bjorn Helgaas
2021-07-13 21:13     ` Heiner Kallweit [this message]
2021-07-14 15:50       ` Bjorn Helgaas
2021-07-15  8:31         ` Heiner Kallweit
2021-05-13 21:02 ` [PATCH 5/5] PCI/VPD: Remove pci_vpd member flag Heiner Kallweit
2021-07-06  5:56 ` [PATCH 0/5] PCI/VPD: Further improvements Heiner Kallweit
2021-07-06 14:32   ` Bjorn Helgaas
2021-07-15 21:59 ` [PATCH 0/5] PCI/VPD: pci_vpd_size() cleanups Bjorn Helgaas
2021-07-15 21:59   ` [PATCH 1/5] PCI/VPD: Correct diagnostic for VPD read failure Bjorn Helgaas
2021-07-15 22:07     ` Heiner Kallweit
2021-07-16  5:58     ` Hannes Reinecke
2021-07-15 21:59   ` [PATCH 2/5] PCI/VPD: Check Resource tags against those valid for type Bjorn Helgaas
2021-07-16  5:59     ` Hannes Reinecke
2021-07-15 21:59   ` [PATCH 3/5] PCI/VPD: Consolidate missing EEPROM checks Bjorn Helgaas
2021-07-15 22:16     ` Heiner Kallweit
2021-07-28 23:42       ` Bjorn Helgaas
2021-07-29  6:10         ` Heiner Kallweit
2021-07-29 18:31           ` Bjorn Helgaas
2021-07-16  6:00     ` Hannes Reinecke
2021-07-15 21:59   ` [PATCH 4/5] PCI/VPD: Don't check Large Resource types for validity Bjorn Helgaas
2021-07-16  6:03     ` Hannes Reinecke
2021-07-28 23:46       ` Bjorn Helgaas
2021-07-15 21:59   ` [PATCH 5/5] PCI/VPD: Allow access to valid parts of VPD if some is invalid Bjorn Helgaas
2021-07-16  6:04     ` Hannes Reinecke
2021-08-02 22:32 ` [PATCH 0/5] PCI/VPD: Further improvements Bjorn Helgaas
2021-08-05 19:10   ` Heiner Kallweit
2021-08-05 19:29     ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0fb70529-3b0e-4865-bf6d-460030948019@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=hare@suse.de \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.