All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Bobroff <sbobroff@linux.ibm.com>
To: "Oliver O'Halloran" <oohall@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 3/4] powerpc/eeh: Remove workaround from eeh_add_device_late()
Date: Wed, 8 Apr 2020 16:21:59 +1000	[thread overview]
Message-ID: <20200408062159.GB25852@osmium> (raw)
In-Reply-To: <c7e81c27a6da9f7a4266cec9995b597bce4efc7b.camel@gmail.com>

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

On Fri, Apr 03, 2020 at 05:08:32PM +1100, Oliver O'Halloran wrote:
> On Mon, 2020-03-30 at 15:56 +1100, Sam Bobroff wrote:
> > When EEH device state was released asynchronously by the device
> > release handler, it was possible for an outstanding reference to
> > prevent it's release and it was necessary to work around that if a
> > device was re-discovered at the same PCI location.
> 
> I think this is a bit misleading. The main situation where you'll hit
> this hack is when recovering a device with a driver that doesn't
> implement the error handling callbacks. In that case the device is
> removed, reset, then re-probed by the PCI core, but we assume it's the
> same physical device so the eeh_device state remains active.
> 
> If you actually changed the underlying device I suspect something bad
> would happen.

I'm not sure I understand. Isn't the case you're talking about caught by
the earlier check (just above the patch)?

	if (edev->pdev == dev) {
		eeh_edev_dbg(edev, "Device already referenced!\n");
		return;
	}
> 
> > Now that the state is released synchronously that is no longer
> > possible and the workaround is no longer necessary.
> 
> You could probably fold this into the previous patch, but eh. You could
> probably fold this into the previous patch, but eh.

True.

> > Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
> > ---
> >  arch/powerpc/kernel/eeh.c | 23 +----------------------
> >  1 file changed, 1 insertion(+), 22 deletions(-)
> > 
> > diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> > index c36c5a7db5ca..12c248a16527 100644
> > --- a/arch/powerpc/kernel/eeh.c
> > +++ b/arch/powerpc/kernel/eeh.c
> > @@ -1206,28 +1206,7 @@ void eeh_add_device_late(struct pci_dev *dev)
> >  		eeh_edev_dbg(edev, "Device already referenced!\n");
> >  		return;
> >  	}
> > -
> > -	/*
> > -	 * The EEH cache might not be removed correctly because of
> > -	 * unbalanced kref to the device during unplug time, which
> > -	 * relies on pcibios_release_device(). So we have to remove
> > -	 * that here explicitly.
> > -	 */
> > -	if (edev->pdev) {
> > -		eeh_rmv_from_parent_pe(edev);
> > -		eeh_addr_cache_rmv_dev(edev->pdev);
> > -		eeh_sysfs_remove_device(edev->pdev);
> > -
> > -		/*
> > -		 * We definitely should have the PCI device removed
> > -		 * though it wasn't correctly. So we needn't call
> > -		 * into error handler afterwards.
> > -		 */
> > -		edev->mode |= EEH_DEV_NO_HANDLER;
> > -
> > -		edev->pdev = NULL;
> > -		dev->dev.archdata.edev = NULL;
> > -	}
> > +	WARN_ON_ONCE(edev->pdev);
> >  
> >  	if (eeh_has_flag(EEH_PROBE_MODE_DEV))
> >  		eeh_ops->probe(pdn, NULL);
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-04-08  6:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30  4:56 [PATCH 0/4] powerpc/eeh: Release EEH device state synchronously Sam Bobroff
2020-03-30  4:56 ` [PATCH 1/4] powerpc/eeh: fix pseries_eeh_configure_bridge() Sam Bobroff
2020-04-03  4:19   ` Oliver O'Halloran
2020-03-30  4:56 ` [PATCH 2/4] powerpc/eeh: Release EEH device state synchronously Sam Bobroff
2020-04-03  4:51   ` Oliver O'Halloran
2020-04-08  6:15     ` Sam Bobroff
2020-03-30  4:56 ` [PATCH 3/4] powerpc/eeh: Remove workaround from eeh_add_device_late() Sam Bobroff
2020-04-03  6:08   ` Oliver O'Halloran
2020-04-08  6:21     ` Sam Bobroff [this message]
2020-04-08  6:53       ` Oliver O'Halloran
2020-04-15  6:44         ` Sam Bobroff
2020-03-30  4:56 ` [PATCH 4/4] powerpc/eeh: Clean up edev cleanup for VFs Sam Bobroff
2020-04-03  5:45   ` Oliver O'Halloran
2020-04-08  6:33     ` Sam Bobroff

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=20200408062159.GB25852@osmium \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.