On Mon, 2017-11-20 at 11:53 +0100, Sebastian Siewior wrote: > > To your question whether or not delaying IO can cause any deadlocks is > something that I can't answer and this something that would affect !RT, > too. I tried to add lockdep to bit-spinlocks but this does not work > because one context acquires the lock and another does the unlock. It > has been explained to me that no deadlocks should happen as long as > the IO is flushed before we block/wait on a lock. That wasn't the question (guess I didn't formulate it well). What I was concerned about was the possibility that the situation that caused me to add that __migrate_disabled() qualifier might arise anew, but with different players. At the time, I had to add that qualifier to prevent ABBA between the owner of q->queue_lock, who was blocked by a lock ALREADY held by the task trying to pull its plug, who then met the locked q->queue_lock. Ergo the less than perfect hack to only allow pulling the plug when NOT YET holding a spinlock. The problem was converted spinlocks (and added RT locks). -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
