Michal Kazior <michal.kazior@xxxxxxxxx> writes: >> Sure, but I still think it's a bit ugly. The right way to fix this would >> be to add it to include/lockdep.h, instead of adding custom checks to a >> driver. > > Good point. I wonder if it's generic enough to justify. No idea. But no matter what it will take some time to get it accepted, so we need to solve this in a faster way so that I can apply this patch. >> But does this check even make sense? There's nothing preventing >> to another thread to take lock just after the WARN_ON(), right? > > There's nothing wrong with other thread holding it. Actually that's > the reason for this very check. > > The point is to prevent ath10k_drain_tx() being called while caller > (current thread) holds conf_mutex. If it were to hold conf_mutex then > cancel_work_sync() can deadlock as both workers it tries to stop try > to get a hold of the lock too. Ah, now I understand. What if we just drop the WARN_ON() from this patch just so that I can apply the patch and we add a proper code for checking the mutex in a followup patch? Are you ok with that? -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
