mwifiex: Don't release cmd_pending_q_lock while iterating

Just like in the previous patch ("mwifiex: Don't release
tx_ba_stream_tbl_lock while iterating"), in
mwifiex_cancel_all_pending_cmd() we were itearting over a list protected
by a spinlock.  Again, it is not safe to release the spinlock while
iterating.  Don't do it.

Luckily in this case there should be no need to release the spinlock.
This is evidenced by:

1. The only function called while the spinlock was released was
   mwifiex_recycle_cmd_node()
2. Aside from atomic functions (which are safe to call), the only
   function called by mwifiex_recycle_cmd_node() was
   mwifiex_insert_cmd_to_free_q().
3. It can be seen in mwifiex_cancel_pending_scan_cmd() that it's OK to
   call mwifiex_insert_cmd_to_free_q() while holding a different
   spinlock (scan_pending_q_lock), so in general holding a spinlock
   should be OK.
4. It doesn't appear that mwifiex_insert_cmd_to_free_q() has any
   interaction with the cmd_pending_q_lock

No known bugs are fixed with this change, but as with other similar
changes this could fix random list corruption.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

0 files changed, 0 insertions, 0 deletions