linux-kernel - RE: [PATCH] PCI Hotplug: fakephp: fix deadlock... again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Sep 2008 23:03:26 +0800
From:	"Zhao, Yu" <yu.zhao@...el.com>
To:	"Alex Chiang" <achiang@...com>, <jbarnes@...tuousgeek.org>
Cc:	"Greg KH" <gregkh@...e.de>, "Matthew Wilcox" <matthew@....cx>,
	<linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] PCI Hotplug: fakephp: fix deadlock... again

Thanks for the fix.

Acked-by: Yu Zhao <yu.zhao@...el.com>

On Tuesday, September 02, 2008 2:40 AM, Alex Chiang wrote:
>* Zhao, Yu <yu.zhao@...el.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@...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@...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;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/