[BUG] ipw2100: possible deadlocks involving waiting and locking operations

Hello,

My static analysis tool reports two possible deadlock in the ipw2100 
driver in Linux 5.16:

#BUG 1
ipw2100_wx_set_retry()
   mutex_lock(&priv->action_mutex); --> Line 7323 (Lock A)
   ipw2100_set_short_retry()
     ipw2100_hw_send_command()
       wait_event_interruptible_timeout(priv->wait_command_queue, ...) 
--> Line 793 (Wait X)

ipw_radio_kill_sw()
   mutex_lock(&priv->action_mutex); --> Line 4259 (Lock A)
   schedule_reset()
     wake_up_interruptible(&priv->wait_command_queue); --> Line 706 (Wake X)

#BUG 2
ipw2100_wx_set_scan()
   mutex_lock(&priv->action_mutex); --> Line 7393 (Lock A)
   ipw2100_start_scan()
     ipw2100_hw_send_command()
       wait_event_interruptible_timeout(priv->wait_command_queue, ...) 
--> Line 793 (Wait X)

ipw_radio_kill_sw()
   mutex_lock(&priv->action_mutex); --> Line 4259 (Lock A)
   schedule_reset()
     wake_up_interruptible(&priv->wait_command_queue); --> Line 706 (Wake X)

When ipw2100_wx_set_retry() or ipw2100_wx_set_scan() is executed, "Wait 
X" is performed by holding "Lock A". If ipw_radio_kill_sw() is executed 
at this time, "Wake X" cannot be performed to wake up "Wait X", because 
"Lock A" has been already hold, causing possible deadlocks.
I find that "Wait X" is performed with a timeout, to relieve the 
possible deadlocks; but I think this timeout can cause inefficient 
execution.

I am not quite sure whether these possible problems are real.
Any feedback would be appreciated, thanks :)


Best wishes,
Jia-Ju Bai