Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux