linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rustad, Mark D" <mark.d.rustad@intel.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "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: [PATCH] pci: Use a bus-global mutex to protect VPD operations
Date: Wed, 27 May 2015 19:11:05 +0000	[thread overview]
Message-ID: <151DE2D4-7D19-48B1-8317-9470F03B400D@intel.com> (raw)
In-Reply-To: <20150527172741.GX32152@google.com>

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

> On May 27, 2015, at 10:27 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> 
> It sounds like there are real problems here that would be fixed by changing
> the mutex strategy and limiting VPD read lengths, but that we don't quite
> have consensus on how to solve them yet.

I have a new pair of patches that I am getting internal feedback on. I
will be on vacation starting tomorrow and won't be back until Tuesday, so
I think it best to send them when I get back so that I will be available
to respond. I could be convinced to send them now.

> VPD is a bit of a tar pit.

It sure is.

> We've talked about limiting VPD read length
> before (see links below), which requires interpreting the VPD contents
> (just the tags & sizes) the kernel.  I think I'm OK with doing that,
> provided we should audit existing users and make sure we don't break them.
> 
> http://lkml.kernel.org/r/c67cd7f4-8d8f-48fc-a63c-dbdafde873a2@CMEXHTCAS1.ad.emulex.com
> http://lkml.kernel.org/r/1f6d7b6c-7189-4fe3-926b-42609724cab9@CMEXHTCAS2.ad.emulex.com
> 
> I'd also like to include specifics, e.g., bugzillas with complete dmesg and
> lspci information, for the problems we're fixing.

The issue I am addressing is for when the VPD Address/F and Data registers
are shared across multiple functions. My latest patch addresses this by
always performing the access through function 0. I added a dev_flags bit
to indicate when this should be done, so only devices that have a quirk
that sets that bit will get that treatment.

The patch I have still doesn't address the issue for direct-assigned
devices. I have no answer to that, but will point out that most guests
seem to use virtual machines that don't support extended config space
anyway. Only those that do support extended config space and access VPD
could be a source of trouble.

I have to say that I haven't actually reproduced the failure, but given
the design of the hardware it is clear that somehow a common mutex needs
to protect those shared registers.

--
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-27 19:11 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
2015-05-20 21:26             ` Alexander Duyck
2015-05-27 17:27 ` Bjorn Helgaas
2015-05-27 19:11   ` Rustad, Mark D [this message]

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=151DE2D4-7D19-48B1-8317-9470F03B400D@intel.com \
    --to=mark.d.rustad@intel.com \
    --cc=bhelgaas@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --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).