Re: [PATCH(v3) 2.6.24] Fix fakephp deadlock

[Andrew Morton <akpm@linux-foundation.org>]

> On Fri, 25 Jan 2008 16:23:56 +0000 Ian Abbott <abbotti@mev.co.uk> wrote:
> From: Ian Abbott <abbotti@mev.co.uk>
> 
> 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.