From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81EFEC4167D for ; Mon, 7 Feb 2022 07:02:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230121AbiBGHAX (ORCPT ); Mon, 7 Feb 2022 02:00:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244239AbiBGGjS (ORCPT ); Mon, 7 Feb 2022 01:39:18 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 859F4C043184; Sun, 6 Feb 2022 22:39:17 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6330A608CC; Mon, 7 Feb 2022 06:39:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02037C004E1; Mon, 7 Feb 2022 06:39:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644215955; bh=x0+qU7jW+I6pS9yDRMI6eYb/c2RxQC1bhyeo7aFHyY0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hQ0Q1uPSjrKlkH+8zu3b1QjeLuuhFlRFXuI+pbSDJ3NfbIaJR9kKLKcWsg/kjF+lX M5dNenFMXdjFaGtmzYbHHOL0BMwfAl8xdRZoGXDa4AMPzasTH6er+lFw1vwP24VbRM 8ingmHtZySUbzYn9UNfqamBqSO70IEZg7tVW2r4iEq6GCt0LrZRpe+2DU332ZsZE4c DEt7pG6yPpEVk1o9P5MDYPOLmjxuYpgRw4m/vxAzKQ0nA/IvxPN+2f33beEeZD/rcP O96G7vOJuzFQwxcayzcP/1YEFLmHx84iRX52XLJKH5vIhRWsYR1gWXoO4S11kKig5x Vx+28MxMz4zzA== Date: Mon, 7 Feb 2022 12:09:08 +0530 From: Manivannan Sadhasivam To: Jia-Ju Bai Cc: hemantk@codeaurora.org, bbhatt@codeaurora.org, loic.poulain@linaro.org, jhugo@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-kernel Subject: Re: [BUG] bus: mhi: possible deadlock in mhi_pm_disable_transition() and mhi_async_power_up() Message-ID: <20220207063908.GB1905@thinkpad> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi, Thanks for the report! On Sat, Jan 29, 2022 at 10:56:30AM +0800, Jia-Ju Bai wrote: > Hello, > > My static analysis tool reports a possible deadlock in the mhi driver in > Linux 5.10: > > mhi_async_power_up() >   mutex_lock(&mhi_cntrl->pm_mutex); --> Line 933 (Lock A) >   wait_event_timeout(mhi_cntrl->state_event, ...) --> Line 985 (Wait X) >   mutex_unlock(&mhi_cntrl->pm_mutex); --> Line 1040 (Unlock A) > > mhi_pm_disable_transition() >   mutex_lock(&mhi_cntrl->pm_mutex); --> Line 463 (Lock A) >   wake_up_all(&mhi_cntrl->state_event); --> Line 474 (Wake X) >   mutex_unlock(&mhi_cntrl->pm_mutex); --> Line 524 (Unlock A) >   wake_up_all(&mhi_cntrl->state_event); --> Line 526 (Wake X) > > When mhi_async_power_up() is executed, "Wait X" is performed by holding > "Lock A". If mhi_pm_disable_transition() is concurrently executed at this > time, "Wake X" cannot be performed to wake up "Wait X" in > mhi_async_power_up(), because "Lock A" is already hold by > mhi_async_power_up(), causing a possible deadlock. > I find that "Wait X" is performed with a timeout, to relieve the possible > deadlock; but I think this timeout can cause inefficient execution. > As per the MHI design, we can be sure that mhi_pm_disable_transition() won't be called until wait_event_timeout() completes in mhi_async_power_up(). So this deadlock is not possible in practical. Thanks, Mani > I am not quite sure whether this possible problem is real and how to fix it > if it is real. > Any feedback would be appreciated, thanks :) > > > Best wishes, > Jia-Ju Bai > > >