> On Fri, 25 Jan 2008 16:23:56 +0000 Ian Abbott <[EMAIL PROTECTED]> wrote:
> From: Ian Abbott <[EMAIL PROTECTED]>
>
> If the fakephp driver is used to emulate removal of a PCI device by
> writing text string "0" to the "power" sysfs attribute file, this causes
> its parent directory and its contents (including the "power" file) to be
> deleted before the write operation returns. Unfortunately, it ends up
> in a deadlock waiting for itself to complete.
Thansk for working on this, but....
> The deadlock is as follows: sysfs_write_file calls flush_write_buffer
> which calls sysfs_get_active_two before calling power_write_file in
> pci_hotplug_core.c via the sysfs store operation. The power_write_file
> function calls disable_slot in fakephp.c via the slot operation. The
> disable_slot function calls remove_slot which calls pci_hp_deregister
> (back in pci_hotplug_core.c) which calls fs_remove_slot which calls
> sysfs_remove_file to remove the "power" file. The sysfs_remove_file
> function calls sysfs_hash_and_remove which calls sysfs_addrm_finish
> which calls sysfs_deactivate. The sysfs_deactivate function sees that
> something has an active reference on the sysfs_dirent (from the
> previous call to sysfs_get_active_two back up the call stack somewhere)
> so waits for the active reference to go away, which is of course
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <- this always wrong
> impossible.
>
> The problem has been present since 2.6.21.
>
> This patch breaks the deadlock by queuing work queue items on a single-
> threaded work queue to remove a slot from sysfs, and to rescan the PCI
> buses. There is also some protection against disabling a slot that is
> already being removed.
Adding a deferred-work like this just because we can't get the locking and
refcounting correct is a really sad hack.
Can we get the locking and refcounting right please? Start by making that
wait-for-refcount-to-go-away go away.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
