From: Mikulas Patocka <mpatocka@redhat.com>
To: Runyu Xiao <runyu.xiao@seu.edu.cn>
Cc: agk@redhat.com, snitzer@kernel.org, dm-devel@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
jianhao.xu@seu.edu.cn
Subject: Re: [PATCH] dm-crypt: unlock allocation mutex before retry
Date: Mon, 10 Aug 2026 11:46:29 +0200 (CEST) [thread overview]
Message-ID: <36ae1bb3-09ad-77a2-15fb-4fa76208ad0c@redhat.com> (raw)
In-Reply-To: <20260809051839.3504080-1-runyu.xiao@seu.edu.cn>
On Sun, 9 Aug 2026, Runyu Xiao wrote:
> If the initial GFP_NOWAIT page allocation fails, crypt_alloc_buffer()
> sets __GFP_DIRECT_RECLAIM and retries while holding bio_alloc_lock. If a
> later page allocation fails, the retry edge bypasses the common unlock and
> reacquires the same mutex. This can deadlock the dm-crypt I/O path and
> leave I/O for the affected mapping stalled.
Hi
When __GFP_DIRECT_RECLAIM is set, mempool_alloc can't return NULL. So, the
bug can't happen.
Mikulas
> Release the mutex before retrying, but only when this attempt took the
> direct-reclaim path; the first attempt did not acquire it.
>
> This issue was identified by a static-analysis checker and manually
> confirmed by following the retry control flow in v6.1.66 and current
> mainline. A source-level control-flow check verified the vulnerable
> ordering and the unlock-before-retry ordering after this change. A small
> POSIX-thread model checked only the mutex re-acquisition condition; it does
> not exercise dm-crypt.
>
> Fixes: 7145c241a1bf ("dm crypt: avoid deadlock in mempools")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
> ---
> drivers/md/dm-crypt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
> index 608b617fb817..aabb9a5f85a7 100644
> --- a/drivers/md/dm-crypt.c
> +++ b/drivers/md/dm-crypt.c
> @@ -1674,6 +1674,8 @@ static struct bio *crypt_alloc_buffer(struct dm_crypt_io *io, unsigned int size)
> if (!pages) {
> crypt_free_buffer_pages(cc, clone);
> bio_put(clone);
> + if (unlikely(gfp_mask & __GFP_DIRECT_RECLAIM))
> + mutex_unlock(&cc->bio_alloc_lock);
> gfp_mask |= __GFP_DIRECT_RECLAIM;
> order = 0;
> goto retry;
> --
> 2.34.1
>
prev parent reply other threads:[~2026-08-10 9:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 5:18 [PATCH] dm-crypt: unlock allocation mutex before retry Runyu Xiao
2026-08-09 13:20 ` Bart Van Assche
2026-08-11 3:14 ` [PATCH v2] dm-crypt: refactor buffer allocation retry handling Runyu Xiao
2026-08-11 11:55 ` Mikulas Patocka
2026-08-11 14:08 ` Runyu Xiao
2026-08-10 9:46 ` Mikulas Patocka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36ae1bb3-09ad-77a2-15fb-4fa76208ad0c@redhat.com \
--to=mpatocka@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=jianhao.xu@seu.edu.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=runyu.xiao@seu.edu.cn \
--cc=snitzer@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.