Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Miquel Raynal <miquel.raynal@bootlin.com>
To:     Duoming Zhou <duoming@zju.edu.cn>, linux-mtd@lists.infradead.org
Cc:     Miquel Raynal <miquel.raynal@bootlin.com>, richard@nod.at,
        vigneshr@ti.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: Fix deadlock caused by cancel_work_sync in sm_release
Date:   Thu,  9 Jun 2022 14:42:53 +0200
Message-Id: <20220609124253.133037-1-miquel.raynal@bootlin.com>
In-Reply-To: <20220524044841.10517-1-duoming@zju.edu.cn>
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Tue, 2022-05-24 at 04:48:41 UTC, Duoming Zhou wrote:
> There is a deadlock between sm_release and sm_cache_flush_work
> which is a work item. The cancel_work_sync in sm_release will
> not return until sm_cache_flush_work is finished. If we hold
> mutex_lock and use cancel_work_sync to wait the work item to
> finish, the work item also requires mutex_lock. As a result,
> the sm_release will be blocked forever. The race condition is
> shown below:
> 
>     (Thread 1)             |   (Thread 2)
> sm_release                 |
>   mutex_lock(&ftl->mutex)  | sm_cache_flush_work
>                            |   mutex_lock(&ftl->mutex)
>   cancel_work_sync         |   ...
> 
> This patch moves del_timer_sync and cancel_work_sync out of
> mutex_lock in order to mitigate deadlock.
> 
> Fixes: 7d17c02a01a1 ("mtd: Add new SmartMedia/xD FTL")
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.

Miquel