Hello Neil, On Wednesday, 6. April 2011 12:16:00 Tejun Heo wrote: > > To put it another way matching your description Tejun, the put path has > > a chance to run firstly while mddev_find is waiting for the spinlock, > > and then while flush_workqueue is waiting for the rest of the put path > > to complete. > > I don't think the logic is wrong per-se. It's more likely that the > implemented code doesn't really follow the model described by the > logic. > > Probably the best way would be reproducing the problem and throwing in > some diagnostic code to tell the sequence of events? If work is being > queued first but it still ends up busy looping, that would be a bug in > flush_workqueue(), but I think it's more likely that the restart > condition somehow triggers in an unexpected way without the work item > queued as expected. I can test any debug patch you want, the box is in a test lab anyway. Best regards, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html