On Feb 16 Chris Boot wrote: > Reading about mutexes though I see I can't use them from interrupt > context, but doesn't the FireWire address handler execute in interrupt > context? I have to check the state of the management agent in the > address handler to properly reject requests from the initiator when the > agent is busy. I guess a spinlock is called for in this situation, > possibly using spin_trylock() in the address handler to avoid blocking? Yes; the request-receive callback (address handler) is executed in tasklet context. All drivers which use this currently use the spin_lock_irqsave API variant. I am considering to change the entire subsystem to use spin_lock_bh only. IMO you could use spin_lock_bh in your target code, or spin_lock for locks which are _only_ ever taken in tasklet context. Plain spin_lock cannot be used, neither in the address handler nor in any process context which grabs the same lock as the address handler. The use cases for trylock variants of the locking APIs are somewhat special. If in doubt, ignore that trylock APIs exist. In strict terms, spin_trylock avoids busy-waiting for a contended lock. mutex_trylock avoids blocking in the sense of sleeping wait for a contended mutex. However, to expand on the obvious, the trylock variants are only useful if whatever action which was meant to be performed can be aborted without problem, e.g. if upper layers would be able to retry at some later occasion. (I am still interested in closer looks at the execution contexts and object lifetime rules in your code, but spare time vs. mental capacity seem regularly at odds...) -- Stefan Richter -=====-===-- --=- =---- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
