[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <177036249397.3323736.12618812589949729211.b4-ty@kernel.org>
Date: Fri, 6 Feb 2026 08:24:38 +0100
From: "Christophe Leroy (CS GROUP)" <chleroy@...nel.org>
To: CHAMPSEIX Thomas <thomas.champseix@...tomgroup.com>,
Marco Crivellari <marco.crivellari@...e.com>,
Kees Cook <kees@...nel.org>,
Roy Pledge <roy.pledge@....com>,
Claudiu Manoil <claudiu.manoil@....com>,
Scott Wood <oss@...error.net>,
Richard Genoud <richard.genoud@...tlin.com>
Cc: Christophe Leroy <chleroy@...nel.org>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
linuxppc-dev@...ts.ozlabs.org,
linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] soc: fsl: qbman: fix race condition in qman_destroy_fq
On Tue, 23 Dec 2025 08:25:49 +0100, Richard Genoud wrote:
> 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 = fqid;
> fq->idx = fqid * 2;
> WARN_ON(fq_table[fq->idx]);
> fq_table[fq->idx] = fq;
> fq_table[fq->idx] = NULL;
>
> [...]
Applied, thanks!
[1/1] soc: fsl: qbman: fix race condition in qman_destroy_fq
(no commit info)
Best regards,
--
Christophe Leroy (CS GROUP) <chleroy@...nel.org>
Powered by blists - more mailing lists