All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Hannes Reinecke <hare@suse.de>,
	linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 3/5] PCI/VPD: Consolidate missing EEPROM checks
Date: Thu, 29 Jul 2021 08:10:25 +0200	[thread overview]
Message-ID: <0e9c09b3-c964-2b34-5d67-db013a9258ae@gmail.com> (raw)
In-Reply-To: <20210728234245.GA868725@bjorn-Precision-5520>

On 29.07.2021 01:42, Bjorn Helgaas wrote:
> On Fri, Jul 16, 2021 at 12:16:55AM +0200, Heiner Kallweit wrote:
>> On 15.07.2021 23:59, Bjorn Helgaas wrote:
>>> From: Bjorn Helgaas <bhelgaas@google.com>
>>>
>>> A missing VPD EEPROM typically reads as either all 0xff or all zeroes.
>>> Both cases lead to invalid VPD resource items.  A 0xff tag would be a Large
>>> Resource with length 0xffff (65535).  That's invalid because VPD can only
>>> be 32768 bytes, limited by the size of the address register in the VPD
>>> Capability.
>>>
>>> A VPD that reads as all zeroes is also invalid because a 0x00 tag is a
>>> Small Resource with length 0, which would result in an item of length 1.
>>> This isn't explicitly illegal in PCIe r5.0, sec 6.28, but the format is
>>> derived from PNP ISA, which *does* say "a small resource data type may be
>>> 2-8 bytes in size" (Plug and Play ISA v1.0a, sec 6.2.2.
>>>
>>> Check for these invalid tags and return VPD size of zero if we find them.
>>> If they occur at the beginning of VPD, assume it's the result of a missing
>>> EEPROM.
>>>
>>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>> ---
>>>  drivers/pci/vpd.c | 36 +++++++++++++++++++++++++++---------
>>>  1 file changed, 27 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
>>> index 9b54dd95e42c..9c2744d79b53 100644
>>> --- a/drivers/pci/vpd.c
>>> +++ b/drivers/pci/vpd.c
>>> @@ -77,11 +77,7 @@ static size_t pci_vpd_size(struct pci_dev *dev, size_t old_size)
>>>  
>>>  	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;
>>> -		}
>>> +		size_t size;
>>>  
>>>  		if (header[0] & PCI_VPD_LRDT) {
>>>  			/* Large Resource Data Type Tag */
>>> @@ -96,8 +92,16 @@ static size_t pci_vpd_size(struct pci_dev *dev, size_t old_size)
>>>  						 off + 1);
>>>  					return 0;
>>>  				}
>>> -				off += PCI_VPD_LRDT_TAG_SIZE +
>>> -					pci_vpd_lrdt_size(header);
>>> +				size = pci_vpd_lrdt_size(header);
>>> +
>>> +				/*
>>> +				 * Missing EEPROM may read as 0xff.
>>> +				 * Length of 0xffff (65535) cannot be valid
>>> +				 * because VPD can't be that large.
>>> +				 */
>>
>> I'm not fully convinced. Instead of checking for a "no VPD EPROM" read (00/ff)
>> directly, we now do it indirectly based on the internal tag structure.
>> We have pci_vpd_lrdt_size() et al to encapsulate the internal structure.
>> IMO the code is harder to understand now.
> 
> I don't quite follow.  Previously we checked for 0x00 data
> ("if (!header[0] && !off)"), but we didn't check directly for 0xff.
> 
> If we read 0xff, we took the PCI_VPD_LRDT case, but it wouldn't match
> ID_STRING, RO_DATA, or RW_DATA, so we'd fall out and check again
> against ID_STRING, RO_DATA, and RW_DATA, and take the "invalid
> %s VPD tag" error path because it doesn't match any.
> 
> This results in failure for any large resource except ID_STRING,
> RO_DATA, and RW_DATA, regardless of the size.
> 
> My proposed code catches a different set of invalid things.
> "size > PCI_VPD_MAX_SIZE" will catch any large resource headers with
> length 0x8001 through 0xffff.
> 
> Possibly it should actually check for "off + size > PCI_VPD_MAX_SIZE"
> so e.g., it would catch a 0x20 byte resource starting at 0x7ff0.
> 

For handling the 0xff case w/o additional overhead the following is pending:
https://patchwork.kernel.org/project/linux-pci/patch/8de8c906-9284-93b9-bb44-4ffdc3470740@gmail.com/

As far as I can see the VPD structure hasn't changed since it was
introduced in PCI 2.2. This was how many years ago?
Instead of adding code at least my personal objective would be
to make support for such legacy features as simple and maintainable
as possible.

>>> +				if (size > PCI_VPD_MAX_SIZE)
>>> +					goto error;
>>> +				off += PCI_VPD_LRDT_TAG_SIZE + size;
>>>  			} else {
>>>  				pci_warn(dev, "invalid large VPD tag %02x at offset %zu",
>>>  					 tag, off);
>>> @@ -105,14 +109,28 @@ static size_t pci_vpd_size(struct pci_dev *dev, size_t old_size)
>>>  			}
>>>  		} else {
>>>  			/* Short Resource Data Type Tag */
>>> -			off += PCI_VPD_SRDT_TAG_SIZE +
>>> -				pci_vpd_srdt_size(header);
>>>  			tag = pci_vpd_srdt_tag(header);
>>> +			size = pci_vpd_srdt_size(header);
>>> +
>>> +			/*
>>> +			 * Missing EEPROM may read as 0x00.  A small item
>>> +			 * must be at least 2 bytes.
>>> +			 */
>>> +			if (size == 0)
>>> +				goto error;
>>> +
>>> +			off += PCI_VPD_SRDT_TAG_SIZE + size;
>>>  			if (tag == PCI_VPD_STIN_END)	/* End tag descriptor */
>>>  				return off;
>>>  		}
>>>  	}
>>>  	return 0;
>>> +
>>> +error:
>>> +	pci_info(dev, "invalid VPD tag %#04x at offset %zu%s\n",
>>> +		 header[0], off, off == 0 ?
>>> +		 "; assume missing optional EEPROM" : "");
>>> +	return 0;
>>>  }
>>>  
>>>  /*
>>>
>>


  reply	other threads:[~2021-07-29  6:10 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
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 [this message]
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=0e9c09b3-c964-2b34-5d67-db013a9258ae@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.