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