All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Michal Kubecek <mkubecek@suse.com>,
	"Shane M. Seymour" <shane.seymour@hpe.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Bjorn Helgaas <helgaas@kernel.org>
Subject: Re: [PATCH 2/2] pci: Update VPD size with correct length
Date: Fri, 18 Dec 2015 15:14:22 +0100	[thread overview]
Message-ID: <567414BE.5090800@suse.de> (raw)
In-Reply-To: <CAKgT0Uc9vZGHvtUuzv4EkE2d4-U5F=22-YeSAOWBH=vGa4yJ5Q@mail.gmail.com>

On 12/18/2015 03:02 PM, Alexander Duyck wrote:
> On Fri, Dec 18, 2015 at 5:57 AM, Hannes Reinecke <hare@suse.de> wrote:
>> On 12/18/2015 02:49 PM, Alexander Duyck wrote:
>>>
>>> On Fri, Dec 18, 2015 at 12:35 AM, Hannes Reinecke <hare@suse.de> wrote:
>>>>
>>>> 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. And to make
>>>> matters worse not every PCI card implements this properly, leaving
>>>> us with no 'end' marker or even completely invalid data.
>>>> This path modifies the size of the VPD attribute to the available
>>>> size, or set it to '0' if no valid data could be read.
>>>
>>>
>>> This isn't what I had in mind.  There is no need to add an f0 version
>>> of the size function.  The size for all functions other than function
>>> 0 when the F0 flag is set is 0.  We aren't going to be reading their
>>> VPD, we only read the VPD region of function 0.
>>>
>> Ah. (I'm a bit confused about the proposed action for VPD other than
>> function 0).
>> So the idea here is to _disallow_ access to VPDs from functions other than
>> '0' unless these functions have different PCI IDs?
>
> If you take a look at the F0 functions what they do is bypass the VPD
> of the functions other than function 0.  As such setting the size to 0
> should really have no effect since the VPD of the function isn't
> actually read if the F0 flag is set.
>
Setting the size to '0' effectively inhibits you to read the VPD 
data. So if we were to return '0' for PCI devices with the F0 bit 
set we will never ever to be able to read (or write) _any_ VPD data 
for that PCI device/function.
Which would be rendering all these F0 accessors pointless, and we 
might as well remove them.

Hence my confusion.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

  reply	other threads:[~2015-12-18 14:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-18  8:35 [PATCHv4 0/2] PCI: Safe VPD access Hannes Reinecke
2015-12-18  8:35 ` [PATCH 1/2] pci: Update VPD definitions Hannes Reinecke
2015-12-18  8:35 ` [PATCH 2/2] pci: Update VPD size with correct length Hannes Reinecke
2015-12-18 13:49   ` Alexander Duyck
2015-12-18 13:57     ` Hannes Reinecke
2015-12-18 14:02       ` Alexander Duyck
2015-12-18 14:14         ` Hannes Reinecke [this message]
2015-12-29  5:29           ` Jordan_Hargrave
2015-12-29 17:48             ` Alexander Duyck
2015-12-29 19:01               ` Jordan_Hargrave
2015-12-29 20:26                 ` Alexander Duyck
  -- strict thread matches above, loose matches on Subject: below --
2015-12-17  7:59 [PATCHv3 0/2] PCI: Safe VPD access Hannes Reinecke
2015-12-17  7:59 ` [PATCH 2/2] pci: Update VPD size with correct length Hannes Reinecke
2015-12-17 11:06   ` Seymour, Shane M
2015-12-17 11:10   ` kbuild test robot
2015-12-17 17:13   ` Alexander Duyck
2015-12-18  7:44     ` Hannes Reinecke

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=567414BE.5090800@suse.de \
    --to=hare@suse.de \
    --cc=alexander.duyck@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mkubecek@suse.com \
    --cc=shane.seymour@hpe.com \
    /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.