Message-ID: <sashiko-outbox-193718@kernel.org>
From: sashiko-bot@kernel.org
Subject: Re: [PATCH] padata: fix lockdep warning in padata_find_next()
Reply-To: sashiko-reviews@lists.linux.dev
To: "Tristan Madani" <tristmd@gmail.com>, steffen.klassert@secunet.com, daniel.m.jordan@oracle.com
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org, "Tristan
 Madani" <tristan@talencesecurity.com>
In-Reply-To: <20261102155353.1268322-1-tristan@talencesecurity.com>
References: <20261102155353.1268322-1-tristan@talencesecurity.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Mon, 02 Nov 2026 16:00:55 +0000
Precedence: list

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Medium] padata: redundant spin_lock_nested() in padata_find_next() split=
s lock class
--

commit d8de136037d32da1b6bd4096b78d163c014e8d23
Author: Tristan Madani <tristmd@gmail.com>

padata: fix lockdep warning in padata_find_next()

This commit replaces spin_lock() with spin_lock_nested() in
padata_find_next() to annotate acquiring reorder->lock while
padata_reorder() holds squeue->serial.lock.

> diff --git a/kernel/padata.c b/kernel/padata.c
> index 5a113c667d4cb..94d7880a001c4 100644
> --- a/kernel/padata.c
> +++ b/kernel/padata.c
> @@ -253,7 +253,7 @@ static struct padata_priv *padata_find_next(struct pa=
rallel_data *pd, int cpu,
> =20
>  	reorder =3D per_cpu_ptr(pd->reorder_list, cpu);
> =20
> -	spin_lock(&reorder->lock);
> +	spin_lock_nested(&reorder->lock, SINGLE_DEPTH_NESTING);

[Severity: Medium]
Is this spin_lock_nested() annotation still needed here, and does it split
reorder->lock across two lockdep subclasses?

In Linux, spin_lock_init() assigns a lock_class_key per macro expansion site
rather than per C struct type. Historically, squeue->serial.lock and
reorder->lock shared a lockdep class because both were initialized via a
common helper __padata_list_init() (and padata_find_next() was moved inside
squeue->serial.lock in commit 71203f68c774 ("padata: Fix list-related race
in padata_find_next"), rather than commit 16295bec6398).

However, commit af3852cda347 ("padata: remove __padata_list_init()") removed
that helper and initialized the two locks at separate spin_lock_init() call
sites in kernel/padata.c:

padata_init_squeues()
	INIT_LIST_HEAD(&squeue->serial.list);
	spin_lock_init(&squeue->serial.lock);

padata_init_reorder_list()
	INIT_LIST_HEAD(&list->list);
	spin_lock_init(&list->lock);

Because squeue->serial.lock and reorder->lock already have distinct lockdep
classes, acquiring reorder->lock inside squeue->serial.lock does not trigger
a recursive locking warning on current kernels.

Meanwhile, padata_do_serial() acquires the same reorder->lock at the default
subclass 0 before calling padata_reorder():

padata_do_serial()
	spin_lock(&reorder->lock);
	...
	spin_unlock(&reorder->lock);

	if (gotit)
		padata_reorder(padata);
			spin_lock(&squeue->serial.lock);
			padata_find_next()
				spin_lock_nested(&reorder->lock, SINGLE_DEPTH_NESTING);

Won't annotating reorder->lock with SINGLE_DEPTH_NESTING in
padata_find_next() while padata_do_serial() acquires it at subclass 0 cause
lockdep to track the same physical lock as two separate subclasses, hiding
lock ordering dependencies between padata_do_serial() and
padata_find_next()?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261102155353.1268=
322-1-tristan@talencesecurity.com?part=3D1