On 23/01/08 17:46, Greg KH wrote:
On Tue, Jan 22, 2008 at 02:28:08PM +0000, Ian Abbott wrote:#include <linux/init.h> #include <linux/string.h> #include <linux/slab.h> +#include <linux/workqueue.h> #include "../pci.h" #if !defined(MODULE) @@ -63,10 +64,13 @@ struct dummy_slot { struct list_head node; struct hotplug_slot *slot; struct pci_dev *dev; + struct work_struct remove_work; + unsigned long removed;You are treating "removed" as an atomic value, so why not just make it an atomic_t?
Because I'm using it as a boolean?
And what is protecting the fact that the flag could be set right after it gets checked? I don't see a lock here :)
Okay, it looks like there might be a race condition between enable_slot() and disable_slot() if some other task calls disable_slot() while enable_slot() is between the test_bit() and flush_workqueue() calls. I can fix that by avoiding the call to flush_workqueue() in enable_slot() and allocating and queueing a work queue item to defer the call to pci_rescan(). And enable_slot() won't then need to check if the slot was marked as removed - it can just go ahead and allocate and queue a work item.
-- -=( Ian Abbott @ MEV Ltd. E-mail: <[EMAIL PROTECTED]> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- -- 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/
