From: Yosry Ahmed <yosry.ahmed@linux.dev>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: syzbot <syzbot+1a517ccfcbc6a7ab0f82@syzkaller.appspotmail.com>,
davem@davemloft.net, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org
Subject: Re: mm: zswap: fix crypto_free_acomp deadlock in zswap_cpu_comp_dead
Date: Wed, 26 Feb 2025 02:08:14 +0000 [thread overview]
Message-ID: <Z753jsValuBdcvnv@google.com> (raw)
In-Reply-To: <Z75tg3wXoDnGtLis@gondor.apana.org.au>
On Wed, Feb 26, 2025 at 09:25:23AM +0800, Herbert Xu wrote:
> On Tue, Feb 25, 2025 at 01:43:41PM +0000, Yosry Ahmed wrote:
> >
> > Interesting, it's weird that crypto_free_acomp() allocates memory. Do you have the specific call path?
>
> crypto_free_acomp does not allocate memory. However, it takes
> the same mutex that is also taken on the allocation path.
>
> The specific call path can be seen in the original report:
>
> https://syzkaller.appspot.com/bug?extid=1a517ccfcbc6a7ab0f82
After staring at this for a while I think the following situation could
be the problem:
Task A running on CPU #1:
crypto_alloc_acomp_node()
Holds scomp_lock
Enters reclaim
Reads per_cpu_ptr(pool->acomp_ctx, cpu)
Task A is descheduled
zswap_cpu_comp_dead(CPU #1) // CPU #1 going offline
Holds per_cpu_ptr(pool->acomp_ctx, cpu))
Calls crypto_free_acomp()
Waits for scomp_lock
Task A running on CPU #2:
Waits for per_cpu_ptr(pool->acomp_ctx, cpu)
DEADLOCK
In this case I think the fix is correct, thanks for looking into it.
Could you please:
(1) Explain the exact scenario in the commit log, I did not understand
it at first, only after looking at the syzbot dashboard for a while (and
I am not sure how long this persists).
(2) Move all the freeing operations outside the mutex? Right now
crypto_free_acomp() was the problematic call but it could be
acomp_request_free() next.
Something like:
static int zswap_cpu_comp_dead(unsigned int cpu, struct hlist_node *node)
{
struct zswap_pool *pool = hlist_entry(node, struct zswap_pool, node);
struct crypto_acomp_ctx *acomp_ctx = per_cpu_ptr(pool->acomp_ctx, cpu);
struct struct acomp_req *req;
struct crypto_acomp *acomp;
u8 *buffer;
if (IS_ERR_OR_NULL(acomp_ctx))
return 0;
mutex_lock(&acomp_ctx->mutex);
req = acomp_ctx->req;
acomp_ctx->req = NULL;
acomp = acomp_ctx->acomp;
acomp_ctx->acomp = NULL;
buffer = acomp_ctx->buffer;
acomp_ctx->buffer = NULL;
mutex_unlock(&acomp_ctx->mutex);
/*
* Do the actual freeing after releasing the mutex to avoid subtle
* locking dependencies causing deadlocks
*/
if (!IS_ERR_OR_NULL(req))
acomp_request_free(req);
if (!IS_ERR_OR_NULL(acomp))
crypto_free_acomp(acomp);
kfree(acomp_ctx->buffer);
return 0;
}
next prev parent reply other threads:[~2025-02-26 2:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 21:53 [syzbot] [crypto?] possible deadlock in crypto_exit_scomp_ops_async syzbot
2025-02-25 8:53 ` mm: zswap: fix crypto_free_acomp deadlock in zswap_cpu_comp_dead Herbert Xu
2025-02-25 10:49 ` Hillf Danton
2025-02-25 13:43 ` Yosry Ahmed
2025-02-26 1:25 ` Herbert Xu
2025-02-26 2:08 ` Yosry Ahmed [this message]
2025-02-26 2:10 ` Herbert Xu
2025-02-26 2:46 ` Yosry Ahmed
2025-02-26 3:08 ` Herbert Xu
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=Z753jsValuBdcvnv@google.com \
--to=yosry.ahmed@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=syzbot+1a517ccfcbc6a7ab0f82@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/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.