On Fri, Mar 25, 2011 at 3:07 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Fri, Mar 25, 2011 at 02:39:03PM -0700, Dan Williams wrote: >> In that sense the scope of what scic_lock protects is limited to the >> core/hardware state machines (essentially a controller firmware-like >> context). Anything that blocks or interfaces with an upper layer runs >> unlocked in the lldd layer, and we don't play any games of dropping >> the lock from the core. Cancelling and flushing timed events is >> really the only place where the lock gets in the way. Having a >> "timer_cancelled" flag for these few cases is the approach the core >> took over dropping the lock, del_timer_sync, and re-validating state. > > If you just want to deactivate a handler and not wait for it to finish > you can simply use del_timer instead of del_timer_sync. But it's still > up to you to make sure all timer handlers have finished before freeing > their containing structures or any other resource that they use, which > tends to be rather complicated, and hard to maintain in the long run. Ok, so that's why I went all the way to recommending a switch to delayed_workqueue. We can bring down the core and ensure all events have seen a cancellation. None of these containing objects are dynamically destroyed outside of driver exit, nor would they care about the switch from timer callback to process context. That final flush is the only elusive bit that is covered by flush_workqueue. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
