Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <49ce0d1f-c302-7fe5-805b-9f505240f683@gmail.com>
Date:   Mon, 7 Feb 2022 23:03:29 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.1
Content-Language: en-US
To:     stas.yakovlev@gmail.com, kvalo@kernel.org, davem@davemloft.net,
        kuba@kernel.org
From:   Jia-Ju Bai <baijiaju1990@gmail.com>
Subject: [BUG] ipw2100: possible deadlocks involving waiting and locking
 operations
Cc:     linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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