All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Chiang <achiang@hp.com>
To: "Zhao, Yu" <yu.zhao@intel.com>, jbarnes@virtuousgeek.org
Cc: Greg KH <gregkh@suse.de>, Matthew Wilcox <matthew@wil.cx>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] PCI Hotplug: fakephp: fix deadlock... again
Date: Mon, 1 Sep 2008 12:40:18 -0600	[thread overview]
Message-ID: <20080901184018.GA14492@ldl.fc.hp.com> (raw)
In-Reply-To: <7A25B56E4BE99C4283EB931CD1A40E110177E4DA@pdsmsx414.ccr.corp.intel.com>

* Zhao, Yu <yu.zhao@intel.com>:
> Just happened to see a change in fakephp when searching usage
> of the pci_remove_bus_device(). I couldn't find the original
> patches, but this
> http://git.kernel.org/?p=linux/kernel/git/jbarnes/pci-2.6.git;a=commitdiff;h=fe99740cac117f208707488c03f3789cf4904957
> shows, the pci_remove_bus_device() was removed while the
> remove_slot() was added in disable_slot(), which means: 1)
> fakephp can't remove pci_dev anymore; 2) deadlock happens
> because remove_slot() tries to remove the sysfs entry calling
> itself.

Sorry about introducing this regression. Does the following patch
fix it for you?

I've tested it on my system, and I can again use fakephp to
remove a device:

sapphire:/sys/bus/pci/slots # echo 0 > fake4/power 
fakephp: disable_slot - physical_slot = fake4
e1000 0000:01:02.1: PCI INT B disabled
GSI 32 (level, low) -> CPU 2 (0x0200) vector 54 unregistered
fakephp: Slot already scheduled for removal
fakephp: removing slot fake4

We get the "slot already scheduled for removal" because that
particular device has 2 functions, and we're creating slots on a
per-slot basis now, not a per-function basis.

Although, I wonder, Willy -- is that really the right thing to
do? Seems like fakephp would be more useful if we did operate on
a per-function basis, and not per-slot. Especially given Yu's
work with SR-IOV, where we can apparently have lots of functions
per a physical device.

Hm?

Thanks.

/ac

From: Alex Chiang <achiang@hp.com>

PCI Hotplug: fakephp: fix deadlock... again

Commit fe99740cac117f208707488c03f3789cf4904957 (construct one
fakephp slot per PCI slot) introduced a regression, causing a
deadlock when removing a PCI device.

We also never actually removed the device from the PCI core.

So we:

	- remove the device from the PCI core
	- do not directly call remove_slot() to prevent deadlock

Yu Zhao reported and diagnosed this defect.

Signed-off-by: Alex Chiang <achiang@hp.com>
---
diff --git a/drivers/pci/hotplug/fakephp.c b/drivers/pci/hotplug/fakephp.c
index 40337a0..146ca9c 100644
--- a/drivers/pci/hotplug/fakephp.c
+++ b/drivers/pci/hotplug/fakephp.c
@@ -320,15 +320,15 @@ static int disable_slot(struct hotplug_slot *slot)
 			return -ENODEV;
 		}
 
+		/* remove the device from the pci core */
+		pci_remove_bus_device(dev);
+
 		/* queue work item to blow away this sysfs entry and other
 		 * parts.
 		 */
 		INIT_WORK(&dslot->remove_work, remove_slot_worker);
 		queue_work(dummyphp_wq, &dslot->remove_work);
 
-		/* blow away this sysfs entry and other parts. */
-		remove_slot(dslot);
-
 		pci_dev_put(dev);
 	}
 	return 0;

  reply	other threads:[~2008-09-01 18:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-21 20:19 refcount leak in pci_get_device()? Alex Chiang
2008-08-21 20:25 ` Matthew Wilcox
2008-08-21 20:47   ` Greg KH
2008-08-21 22:14     ` Alex Chiang
2008-08-30  4:23       ` Zhao, Yu
2008-08-30  5:37         ` Greg KH
2008-08-30  6:20           ` Zhao, Yu
2008-08-31  3:14             ` problems in fakephp (was RE: refcount leak in pci_get_device()?) Zhao, Yu
2008-09-01 18:40               ` Alex Chiang [this message]
2008-09-02  0:10                 ` [PATCH] PCI Hotplug: fakephp: fix deadlock... again Matthew Wilcox
2008-09-02  0:19                   ` Alex Chiang
2008-09-09  4:12                     ` Jesse Barnes
2008-09-09  4:27                       ` Matthew Wilcox
2008-09-09  5:32                         ` Andrew Patterson
2008-09-04 15:03                 ` Zhao, Yu
2008-08-21 22:23     ` refcount leak in pci_get_device()? Jesse Barnes
2008-08-22  1:04       ` Henrique de Moraes Holschuh
2008-08-22  1:09         ` Henrique de Moraes Holschuh
2008-08-21 20:40 ` Greg KH

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=20080901184018.GA14492@ldl.fc.hp.com \
    --to=achiang@hp.com \
    --cc=gregkh@suse.de \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=yu.zhao@intel.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.