From nobody Sun Feb 8 07:58:11 2026 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3070D2C08C4 for ; Tue, 23 Dec 2025 07:25:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766474762; cv=none; b=qh3r3wXt/Gh5F4nGr/ncl7L+wAFuLe/vpwOx+F1kimLd5kT7OTgJCi3POmsZOnvU0d4H+foWFlAIzKiGlsh7SSavRk4am3eAc1dexvuxax9KDcEXO4RFnThOFWNlkvbdMGqVic/54T8tqb5/74PNCVECRM6wIPtwWtbOnT5XgYE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766474762; c=relaxed/simple; bh=vMABfnbm2tANlto7WjK6/XbBrPeM9uv1dBi6/rJtUdQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=KTgYQxUr0PYgv9A2ANiqakI7mSB6Xjo9qu9PY8f7uhiARMbh/W/MZuNuXpCzwczrhB6ZXOGCuN9ltZiMYXo0bH1naZatrDm3bAU9kbYqKqWb9y0zFNmC0vNzy4RndspTilSKXl/4eOcipWBfcpVVMDg19Iv1cRk8wSydqrkME1s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=Mm7ULY/w; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="Mm7ULY/w" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 684144E41D59; Tue, 23 Dec 2025 07:25:57 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 3455960716; Tue, 23 Dec 2025 07:25:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 75C0A10AB08CD; Tue, 23 Dec 2025 08:25:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1766474756; h=from:subject:date:message-id:to:cc:mime-version: content-transfer-encoding; bh=wMhrMczaTdzgw/2Epo64A6mnsiiunjOSoKZrxh5anZM=; b=Mm7ULY/wGVXC8lzdvFLJBUjxYi5ImbP9zti3LmFFHF6jMWuC356Os15s/ubUvZWtGuqTU4 /PSYzTOSIKwmTWY1AlGe5x2orL2N2XvE3jDDo+d/HxSp/v6FntCLbnZxk+ZlxXTaWPqW4M gjvsD2CSDbd2entK3EqdF567JWx/Ki1SVQpVKiRzg1yU5vXG72yXEMcEkVk65lb/3LC4H3 gfYagEhJ+pIr5dtoWte/abNO2sXXxOiibhFaXiZ9TdVzl5MtbFtptlGFvLhnNQWA9WRSHa it+yftasZINrncpy9Q/fJQeNn+Yv3xO25rAGgZMvskNjXA/8O+XaKcCclPfT7A== From: Richard Genoud To: Christophe Leroy , Marco Crivellari , Kees Cook , Roy Pledge , Claudiu Manoil , Scott Wood Cc: Thomas Petazzoni , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Richard Genoud Subject: [PATCH] soc: fsl: qbman: fix race condition in qman_destroy_fq Date: Tue, 23 Dec 2025 08:25:49 +0100 Message-ID: <20251223072549.397625-1-richard.genoud@bootlin.com> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 Content-Type: text/plain; charset="utf-8" When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between fq_table[fq->idx] state and freeing/allocating from the pool and WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered. Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid =3D fqid; fq->idx =3D fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] =3D fq; fq_table[fq->idx] =3D NULL; And adding some logs between qman_release_fqid() and fq_table[fq->idx] =3D NULL makes the WARN_ON() trigger a lot more. To prevent that, ensure that fq_table[fq->idx] is set to NULL before gen_pool_free() is called by using smp_wmb(). Fixes: c535e923bb97 ("soc/fsl: Introduce DPAA 1.x QMan device driver") Signed-off-by: Richard Genoud Tested-by: CHAMPSEIX Thomas --- drivers/soc/fsl/qbman/qman.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) NB: I'm not 100% sure of the need of a barrier here, since even without it, the WARN_ON() wasn't triggered any more. diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c index 6b392b3ad4b1..39a3e7aab6ff 100644 --- a/drivers/soc/fsl/qbman/qman.c +++ b/drivers/soc/fsl/qbman/qman.c @@ -1827,6 +1827,8 @@ EXPORT_SYMBOL(qman_create_fq); =20 void qman_destroy_fq(struct qman_fq *fq) { + int leaked; + /* * We don't need to lock the FQ as it is a pre-condition that the FQ be * quiesced. Instead, run some checks. @@ -1834,11 +1836,29 @@ void qman_destroy_fq(struct qman_fq *fq) switch (fq->state) { case qman_fq_state_parked: case qman_fq_state_oos: - if (fq_isset(fq, QMAN_FQ_FLAG_DYNAMIC_FQID)) - qman_release_fqid(fq->fqid); + /* + * There's a race condition here on releasing the fqid, + * setting the fq_table to NULL, and freeing the fqid. + * To prevent it, this order should be respected: + */ + if (fq_isset(fq, QMAN_FQ_FLAG_DYNAMIC_FQID)) { + leaked =3D qman_shutdown_fq(fq->fqid); + if (leaked) + pr_debug("FQID %d leaked\n", fq->fqid); + } =20 DPAA_ASSERT(fq_table[fq->idx]); fq_table[fq->idx] =3D NULL; + + if (fq_isset(fq, QMAN_FQ_FLAG_DYNAMIC_FQID) && !leaked) { + /* + * fq_table[fq->idx] should be set to null before + * freeing fq->fqid otherwise it could by allocated by + * qman_alloc_fqid() while still being !NULL + */ + smp_wmb(); + gen_pool_free(qm_fqalloc, fq->fqid | DPAA_GENALLOC_OFF, 1); + } return; default: break; base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578 --=20 2.47.3