Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp46735pxb; Mon, 31 Jan 2022 14:51:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJz8eJkVrK2s0de+lFEvlN+hjQzo8ubtX0ESeTI7jjs+ZahTH/xEznTuOwrOQkVOyQzcev1j X-Received: by 2002:a17:902:f54d:: with SMTP id h13mr22456638plf.82.1643669489925; Mon, 31 Jan 2022 14:51:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643669489; cv=none; d=google.com; s=arc-20160816; b=oc0gccbL7NSEVsDTfZc2atesBu98r7L2oVOl87qoxGLLdnNLMTmaxsbR0q2e4TfYU+ ekVDwdR9SImCDJm1yltDC9IKoUb7e9qXPiT1LiBNTQ3XB7H2ypIuyu6xLXbBWOLCEEnA vwYGo9ZZa/k0FO+5Z8MrRJewq1oBkSBhha+p7LvN7ZL0IJYeewgq/qKhnMjcvp0NFZ6M X1DSNtOIYML40RMqPzSc5HabBqoKrZ77V3Ebk1GqWsLzvC3j7BKqvelDaBVHAylU1p0R lqHAQPq4L6g64pq4FWTjtbDbMUyo+Y4i4NcSTzsVOF8sN011OKoJ44PUFG7QCWb2aPXs H9AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :mime-version:user-agent:date:message-id:cc:to:subject:from :dkim-signature; bh=0wA1bSjpr2MlmYkJcC53Ec+AcC37OXjp4rcmLeTeR84=; b=wlT7RXftemNAzh8QsPmrNlBSOfClnZ44gGzCwKWuoOaTg8KE+mFAzJ7WALPKY6bud0 J9XE5bAnNH3HAIG6QwPDoLLbRc08zW6PlbVel4atCXUfilEQkvWPw263Gx3lmSWpjT3B zQA2QgjgJ6UP1nIsNPa7UxvoyJqcihiB7WX3SGN37+200VNnD6anioKY/MrA4HD825YH I2WpCptGH8+ZWcR2mdWl6+BJAgshicKV/9do45lEge5+mdCTOxsjQgD/JORkEdJg5i+/ nEv0WPGhChrmWOUt4yqaf1CpGbDhju/OSSoKNXq1/x/pbOTXrwwCyUt6fag/ISaIMemo 3Ykw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="YU/aftvt"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v14si13769489pgk.382.2022.01.31.14.51.17; Mon, 31 Jan 2022 14:51:29 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="YU/aftvt"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352255AbiA2C4i (ORCPT + 99 others); Fri, 28 Jan 2022 21:56:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229586AbiA2C4h (ORCPT ); Fri, 28 Jan 2022 21:56:37 -0500 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 955DEC061714; Fri, 28 Jan 2022 18:56:37 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id c190-20020a1c9ac7000000b0035081bc722dso5284427wme.5; Fri, 28 Jan 2022 18:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=0wA1bSjpr2MlmYkJcC53Ec+AcC37OXjp4rcmLeTeR84=; b=YU/aftvtmRgn1wce4ABwmW5NTCA5ceQfc7kRFSiED80ZYT22qJ3wORxd5Fmbz3hwN0 d4y88RUACVxWxNrDqG8oqHd/5JyBt72tay7sG33BurBxdpKarlxTM5FDgzLwqcQ91/S0 MaOwP1zHjMwLud1l40qrgCgNUbyH7jDagmgVIcUNg6qP0lYalTC18WP6Vtf+0/j3ajkd O8liNSGRThlXrG7nH5eNKDReTp/hOtS5LgSZMngk3ktf+S8fz3w0QvW7kYdupxpAXzqV RHDJaIdGmSK1t2/m5zoWENXnhs0zrImC7pLoK1Z5Zf+hPAFk439DBLUrmUgSVS0IHy+2 RmZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=0wA1bSjpr2MlmYkJcC53Ec+AcC37OXjp4rcmLeTeR84=; b=Ai0hNaG2YKP8L/uDqlzymxoapewd4rxYihRj43b7w/r+z/yIH6HZTuHoA7qm6ebCGM hiAgTEHm62trZhbauf4juZtAUttUH4c+IaidlWhGeR2ujUHNzLre68GqBzdggA8bvklf 9PeDg4rUDFUqzlqtCEzoD8PoGzCpj4y0MvuEj+jRNyoF+e7mpAM+8ES8QOy4nC3j1Idf NpysL+FAzYEup8D+Bai3ZXV16BVuYB2Nkmi9pWBoxxbpOZFulgBC7Ws4LITIoj2QFXl+ 0DPqpSRbh+8HWk8DxrzUU3hAJsIM3fMtzq9sFPoV7nZU4yxYaWgjMdX1zV6JLvGtpnxR UxsA== X-Gm-Message-State: AOAM533eU/HKL6jH6V6OmFywr5QqWml/ofQH9l0A/9dLunS7xaU3GzB+ s4msY0s38IRCfGkKpvjsIsL0gMqL2UU= X-Received: by 2002:a05:600c:4f8d:: with SMTP id n13mr17749204wmq.45.1643424995853; Fri, 28 Jan 2022 18:56:35 -0800 (PST) Received: from [10.150.0.6] ([64.64.123.23]) by smtp.gmail.com with ESMTPSA id j2sm3575540wms.2.2022.01.28.18.56.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jan 2022 18:56:35 -0800 (PST) From: Jia-Ju Bai Subject: [BUG] bus: mhi: possible deadlock in mhi_pm_disable_transition() and mhi_async_power_up() To: mani@kernel.org, hemantk@codeaurora.org, bbhatt@codeaurora.org, loic.poulain@linaro.org, jhugo@codeaurora.org Cc: linux-arm-msm@vger.kernel.org, linux-kernel Message-ID: Date: Sat, 29 Jan 2022 10:56:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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