On Sat, 2023-10-14 at 09:29 +0200, Simon Horman wrote: > On Sat, Oct 14, 2023 at 10:43:22AM +0800, Edward AD wrote: > > Hi Simon Horman, > > On Fri, 13 Oct 2023 13:06:38 +0200, Simon Horman wrote: > > > I am wondering if you considered moving the rfkill_sync() calls > > > to before &data->mtx is taken, to avoid the need to drop and > > > retake it? > > If you move rfkill_sync() before calling &data->mtx, more code will be added > > because rfkill_sync() is in the loop body. > > Maybe that is true. And maybe that is a good argument for > not taking the approach that I suggested. But I do think it > is simpler from a locking perspective, and that has some merit. > FWIW, I missed this patch and discussion until now, but I already fixed the issue differently: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=f2ac54ebf85615a6d78f5eb213a8bbeeb17ebe5d There was never any need to hold the data->mtx for anything but the list manipulation, and even that isn't _really_ needed since the 'data' is completely fresh and not seen anywhere else yet. (I'll also note that the subject of this thread is wrong since this was never an *actual* deadlock, just a *possible* one reported by lockdep.) johannes
