From: Bjorn Helgaas <bhelgaas@google.com>
To: "Rustad, Mark D" <mark.d.rustad@intel.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: [Intel-wired-lan] [PATCH V3 0/2] pci: Provide a flag to access VPD through function 0
Date: Sat, 11 Jul 2015 14:49:40 -0500 [thread overview]
Message-ID: <CAErSpo5at=C78JbWEA6YKUNhV4vtUMjSiUKcWG0Ad7Gkg+i2VQ@mail.gmail.com> (raw)
In-Reply-To: <C468F237-DBA2-4503-BA99-76CC1FC46999@intel.com>
On Mon, Jul 6, 2015 at 12:31 PM, Rustad, Mark D <mark.d.rustad@intel.com> wrote:
>> On Jun 26, 2015, at 11:04 AM, Rustad, Mark D <mark.d.rustad@intel.com> wrote:
>>
>>> Sorry, Mark, I've just been busy with other issues and haven't had a
>>> chance to look at this yet.
>>
>> Is there any chance of this getting into this merge window?
>
> Well, it has missed the merge window, but this really is a bug fix. These patches address problems that, under race conditions, can corrupt VPD data and under other conditions can cause hangs. In fact I would submit that the reason that the VPD operations have been made interruptible is directly related to hangs caused by the sharing of VPD capability registers between functions. You see, if one function ever performs a VPD write, any subsequent read on any other function that shares those registers will definitely hang.
As a rule, after the merge window closes, I only merge fixes for
things we broke during the merge window or drivers for brand-new
things, where there's no chance of breaking something that used to
work.
It would be nice to have a description of what a user might see when
tripping over this problem and maybe some pointers to problem reports.
I see it fixes concurrent access problems, and I infer that it's
related to sysfs.
Feel free to add a stable tag when you post your patches. I'll try to
remember to add it when merging this. When it's relevant, it's nice
to include the SHA1 of the commit that introduced the bug. But in
this case, I think it's been there "forever."
Bjorn
next prev parent reply other threads:[~2015-07-11 19:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 18:46 [PATCH V3 0/2] pci: Provide a flag to access VPD through function 0 Mark D Rustad
2015-06-03 18:46 ` [PATCH V3 1/2] pci: Add dev_flags bit " Mark D Rustad
2015-06-03 18:47 ` [PATCH V3 2/2] pci: Add VPD quirk for Intel Ethernet devices Mark D Rustad
2015-06-05 21:59 ` [PATCH V3 0/2] pci: Provide a flag to access VPD through function 0 Rustad, Mark D
2015-06-17 16:29 ` Rustad, Mark D
2015-06-17 16:44 ` Bjorn Helgaas
2015-06-26 18:04 ` Rustad, Mark D
2015-07-06 17:31 ` [Intel-wired-lan] " Rustad, Mark D
2015-07-11 19:49 ` Bjorn Helgaas [this message]
2015-06-17 17:23 ` Alexander Duyck
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='CAErSpo5at=C78JbWEA6YKUNhV4vtUMjSiUKcWG0Ad7Gkg+i2VQ@mail.gmail.com' \
--to=bhelgaas@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=linux-pci@vger.kernel.org \
--cc=mark.d.rustad@intel.com \
--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).