On 23 May 2014 12:31, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> wrote: > 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? I'm okay with this as long as we at least have a comment stating that conf_mutex must not be held while calling the function to avoid deadlocks. Michał -- 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
