linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rustad, Mark D" <mark.d.rustad@intel.com>
To: Alexander Duyck <alexander.h.duyck@redhat.com>
Cc: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH] pci: Use a bus-global mutex to protect VPD operations
Date: Wed, 20 May 2015 16:00:46 +0000	[thread overview]
Message-ID: <C73FDF83-62F7-47F4-905A-CD7D482F0709@intel.com> (raw)
In-Reply-To: <555BDD14.2080807@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

> On May 19, 2015, at 6:02 PM, Alexander Duyck <alexander.h.duyck@redhat.com> wrote:
> 
> My suspicion is that we have a number of bugs floating around out there like the Broadcom issue.  Specifically, one of the ones I found was that the r8169 seems to have a similar issue as called out in the email thread at http://permalink.gmane.org/gmane.linux.network/232260.  I'm wondering if we shouldn't add an initializer for the read/write functions that will go through and pull out the 3 or 4 headers from the VPD data needed to get the actual length.  Then it would lock down the VPD and save some serious time on reads since most devices don't have 32K of VPD to read.

That is interesting. I noticed that there are functions already present to find VPD tags. If the VPD were invalid, would this block its being read at all, or would it default to allow reading/writing anything? I don't know if there might be people using Linux to completely write the VPD area. Presumably your idea would prevent rewriting the VPD area to something larger.

--
Mark Rustad, Networking Division, Intel Corporation


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

  reply	other threads:[~2015-05-20 16:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19  0:00 [PATCH] pci: Use a bus-global mutex to protect VPD operations Mark D Rustad
2015-05-19 17:55 ` [Intel-wired-lan] " Alexander Duyck
2015-05-19 18:28   ` Rustad, Mark D
2015-05-19 20:58     ` Alexander Duyck
2015-05-19 21:53       ` Rustad, Mark D
2015-05-19 23:19         ` Alexander Duyck
2015-05-19 23:01   ` Jesse Brandeburg
2015-05-20  0:07     ` Alexander Duyck
2015-05-20  0:34       ` Rustad, Mark D
2015-05-20  1:02         ` Alexander Duyck
2015-05-20 16:00           ` Rustad, Mark D [this message]
2015-05-20 21:26             ` Alexander Duyck
2015-05-27 17:27 ` Bjorn Helgaas
2015-05-27 19:11   ` Rustad, Mark D

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=C73FDF83-62F7-47F4-905A-CD7D482F0709@intel.com \
    --to=mark.d.rustad@intel.com \
    --cc=alexander.h.duyck@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).