From: Michael Ellerman <mpe@ellerman.id.au>
To: Daniel Axtens <dja@axtens.net>, linuxppc-dev@ozlabs.org
Cc: mikey@neuling.org, "Matthew R. Ochs" <mrochs@linux.vnet.ibm.com>,
imunsie@au.ibm.com, Gavin Shan <gwshan@linux.vnet.ibm.com>,
Manoj Kumar <kumarmn@us.ibm.com>, Daniel Axtens <dja@axtens.net>
Subject: Re: powerpc/eeh: Probe after unbalanced kref check
Date: Mon, 17 Aug 2015 18:03:31 +1000 (AEST) [thread overview]
Message-ID: <20150817080331.ED70D1402B6@ozlabs.org> (raw)
In-Reply-To: <1439532199-12099-1-git-send-email-dja@axtens.net>
On Fri, 2015-14-08 at 06:03:19 UTC, Daniel Axtens wrote:
> In the complete hotplug case, EEH PEs are supposed to be released
> and set to NULL. Normally, this is done by eeh_remove_device(),
> which is called from pcibios_release_device().
>
> However, if something is holding a kref to the device, it will not
> be released, and the PE will remain. eeh_add_device_late() has
> a check for this which will explictly destroy the PE in this case.
>
> This check in eeh_add_device_late() occurs after a call to
> eeh_ops->probe(). On PowerNV, probe is a pointer to pnv_eeh_probe(),
> which will exit without probing if there is an existing PE.
>
> This means that on PowerNV, devices with outstanding krefs will not
> be rediscovered by EEH correctly after a complete hotplug. This is
> affecting CXL (CAPI) devices in the field.
>
> Put the probe after the kref check so that the PE is destroyed
> and affected devices are correctly rediscovered by EEH.
>
> Fixes: d91dafc02f42 ("powerpc/eeh: Delay probing EEH device during hotplug")
> Cc: stable@vger.kernel.org
> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
> Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e642d11bdbfe8eb10116
cheers
prev parent reply other threads:[~2015-08-17 8:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-14 6:03 [PATCH] powerpc/eeh: Probe after unbalanced kref check Daniel Axtens
2015-08-14 7:30 ` Gavin Shan
2015-08-17 8:03 ` Michael Ellerman [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=20150817080331.ED70D1402B6@ozlabs.org \
--to=mpe@ellerman.id.au \
--cc=dja@axtens.net \
--cc=gwshan@linux.vnet.ibm.com \
--cc=imunsie@au.ibm.com \
--cc=kumarmn@us.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikey@neuling.org \
--cc=mrochs@linux.vnet.ibm.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 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).