From: Sam Bobroff <sbobroff@linux.ibm.com>
To: "Oliver O'Halloran" <oohall@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/3] powerpc/sriov: Remove VF eeh_dev state when disabling SR-IOV
Date: Thu, 22 Aug 2019 15:49:31 +1000 [thread overview]
Message-ID: <20190822054930.GA25172@tungsten.ozlabs.ibm.com> (raw)
In-Reply-To: <20190821062655.19735-1-oohall@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]
On Wed, Aug 21, 2019 at 04:26:53PM +1000, Oliver O'Halloran wrote:
> When disabling virtual functions on an SR-IOV adapter we currently do not
> correctly remove the EEH state for the now-dead virtual functions. When
> removing the pci_dn that was created for the VF when SR-IOV was enabled
> we free the corresponding eeh_dev without removing it from the child device
> list of the eeh_pe that contained it. This can result in crashes due to the
> use-after-free.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> ---
> No Fixes: here since I'm not sure if the commit that added this actually
> introduced the bug. EEH is amazing.
Yep.
> I suspect backporting this would cause more problems than it solves since
> reliably replicating the crash required enabling memory poisoning and
> hacking a device driver to remove the PCI error handling callbacks so
> the EEH fallback path (which removes and re-probes PCI devices)
> would be used.
I gave this a quick test with some added instrumentation, and I can see
that the new code is used during VF removal and it doesn't cause any new
problems. I agree that even if it's difficult to trigger, it was
definitely a bug.
Reviewed-by: Sam Bobroff <sbobroff@linux.ibm.com>
Tested-by: Sam Bobroff <sbobroff@linux.ibm.com>
> ---
> arch/powerpc/kernel/pci_dn.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c
> index 6556b57..795c4e3 100644
> --- a/arch/powerpc/kernel/pci_dn.c
> +++ b/arch/powerpc/kernel/pci_dn.c
> @@ -244,9 +244,22 @@ void remove_dev_pci_data(struct pci_dev *pdev)
> continue;
>
> #ifdef CONFIG_EEH
> - /* Release EEH device for the VF */
> + /*
> + * Release EEH state for this VF. The PCI core
> + * has already torn down the pci_dev for this VF, but
> + * we're responsible to removing the eeh_dev since it
> + * has the same lifetime as the pci_dn that spawned it.
> + */
> edev = pdn_to_eeh_dev(pdn);
> if (edev) {
> + /*
> + * We allocate pci_dn's for the totalvfs count,
> + * but only only the vfs that were activated
> + * have a configured PE.
> + */
> + if (edev->pe)
> + eeh_rmv_from_parent_pe(edev);
> +
> pdn->edev = NULL;
> kfree(edev);
> }
> --
> 2.9.5
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-08-22 5:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 6:26 [PATCH 1/3] powerpc/sriov: Remove VF eeh_dev state when disabling SR-IOV Oliver O'Halloran
2019-08-21 6:26 ` [PATCH 2/3] powerpc/pcidn: Make VF pci_dn management CONFIG_PCI_IOV specific Oliver O'Halloran
2019-08-22 5:59 ` Sam Bobroff
2019-08-21 6:26 ` [PATCH 3/3] powerpc/pcidn: Warn when sriov pci_dn management is used incorrectly Oliver O'Halloran
2019-08-22 5:59 ` Sam Bobroff
2019-08-22 5:49 ` Sam Bobroff [this message]
2020-01-29 5:17 ` [PATCH 1/3] powerpc/sriov: Remove VF eeh_dev state when disabling SR-IOV Michael Ellerman
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=20190822054930.GA25172@tungsten.ozlabs.ibm.com \
--to=sbobroff@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=oohall@gmail.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).