From nobody Tue Sep 29 05:34:54 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 F17722253A1; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; cv=none; b=gJzTK9wflLoxEliJFH4fhpNfR94qZlvHU1Bf2fXKVDnGIYEgmXf9wtbce0EgvcXSuv7oE7naSWv8TAFgG2EbzYeVduVUl7i08mc7TGACVUxM6vIoGP895vvy7EMHtnkUgaR4NMuvdSkkpxDadRkiNBCGxWcxok5tl4etD5aCT6c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; c=relaxed/simple; bh=2Ef7G09j67/eoUC8SK2Ltteg4MTYzAdNGnUkoyKYleg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=TDcKmDsFslA5kjJDMYNwFHErdhoJyZlgn0ST8Wobe+SIvOCTN9mqeMectceUYg2CSVEZGV8DPVuUhiKmAusapFkw4Q5Yi47W1qPQy4b3d/yEm6JZtiOF8+lHLs5pW7eG3Lmvzit4YUtQQ8+VxyhLs7XN+l6WSffgMBNu0tX794U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hj5LWPR1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hj5LWPR1" Received: by smtp.kernel.org (Postfix) with ESMTPS id ACF41C2BCF6; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1786513696; bh=2Ef7G09j67/eoUC8SK2Ltteg4MTYzAdNGnUkoyKYleg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=hj5LWPR19q3Xoks4xzKyly0Lmc0JovtQdKa/NFqlIzOTVi/c2D0KMLbCV4PDtCxn8 W7O0n2T2Oi7M/xdv2blOn3m4s0gGfAGkwpZMEcZWHCvJqCkdepVEZb8LMjOR4G58DZ kdkxiFUNJECmFZ4xZbkwUcjPrqog2kCFUVZl0jg3H/G3bCez2dlNOldAUxts/+pZPG I2C4OUc3AKBIz9e3sOJtre+k/PejVDuir4ZRmRrtpEkTwnPjBwtGDTjK+D1DkCTMuO nbgUwfrFnAqSPAvLV4I/xIrwBHuTfPGF8lLLjuZNNoympbo3fw65/npQVFBY7yrEyR RxCU174uMPL3A== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CFBFC5B567; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Wed, 12 Aug 2026 13:48:07 +0800 Subject: [PATCH 1/5] powerpc/spufs: fix memory leak of spufs_fs_context in spufs_free_fc() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260812-spufs-fixes-v1-1-449e201d9f64@outlook.com> References: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> In-Reply-To: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , David Howells , Al Viro , Jeremy Kerr , Arnd Bergmann , Paul Mackerras , Luke Browning Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Junrui Luo , Yuhao Jiang , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=1455; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=7tJ0E00IsnJBei3nS8CdVd0Qh/gBecZOpc59xKiGh0k=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrBpOWbe6PYdDbk6eKcG3yuT2bsbKWTKZM88uLaw66 pOXwejldb6jlIVBjItBVkyR5XjBpW8Wvlt0t/hsSYaZw8oEMoSBi1MAJuKrwvDPKIS9wVS0bsm+ ufOuxTn1rIqYMKnaalX4pb0aDw6LPTHiYPin0BNay8Rec2FX46YA1YZni+1YFi74u+HmNc+Y6Ig ey9e8AF6eSFU= X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo spufs_init_fs_context() allocates both a struct spufs_fs_context stored in fc->fs_private and a struct spufs_sb_info stored in fc->s_fs_info. The ->free callback spufs_free_fc() only releases fc->s_fs_info. put_fs_context() never touches fc->fs_private, since releasing it is what ->free() exists for, and vfs_clean_context() calls ->free() and then clears both pointers itself. Every spufs fs_context that is constructed and torn down therefore leaks the struct spufs_fs_context allocation. The leak is reachable without privileges: fsopen() runs ->init_fs_context() before sget_fc() enforces spufs's lack of FS_USERNS_MOUNT. Free fc->fs_private alongside fc->s_fs_info. Fixes: d2e0981c3b9a ("vfs: Convert spufs to use the new mount API") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo --- arch/powerpc/platforms/cell/spufs/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platf= orms/cell/spufs/inode.c index 2b54afb31529..51c432864f02 100644 --- a/arch/powerpc/platforms/cell/spufs/inode.c +++ b/arch/powerpc/platforms/cell/spufs/inode.c @@ -713,6 +713,7 @@ static int spufs_get_tree(struct fs_context *fc) =20 static void spufs_free_fc(struct fs_context *fc) { + kfree(fc->fs_private); kfree(fc->s_fs_info); } =20 --=20 2.51.2 From nobody Tue Sep 29 05:34:54 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 139D82459C5; Wed, 12 Aug 2026 05:48:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; cv=none; b=geyUMdW5FHqsR4WDw6hnGCTr5tkjc1nBXXjIJEh6mS9jiBIc0FKO5akhS3shyu8TPeL7CxEHjYVuc4HBS7nZu7pBw9eH35g75FnUI5G2fKgKBuzD+UXN0jwNeCHIRKI6JCDE+INLEpWUWsfdXWnSxGXxLeoIKYXFsMtOMEH9/D8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; c=relaxed/simple; bh=aXeZzuaCIuplL0yz2Tn0QcTqCwcq7iG9bnnqD0YlXQw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=KGQwyXKsrFBgn0nEEvWDgEG8rUk7+qx4oUPnfAxbNmaAzQU10d1eGSHfueM+CbFvx7y/33XkKUFWOBn+QGJg2B/advTlDHzsSYYIKRqCvp/pv48fqX6N/+SLJW14/wz1rfz3ceI7OA+oxgmtjLX0SQwt7+UGfFAYxkSswW8n73c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sIdkQZ/+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sIdkQZ/+" Received: by smtp.kernel.org (Postfix) with ESMTPS id C73E0C2BCFA; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1786513696; bh=aXeZzuaCIuplL0yz2Tn0QcTqCwcq7iG9bnnqD0YlXQw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=sIdkQZ/+3XTe7vbW3/3X8gdIyeGiUOkutrxARoDpaSRa5sgQmOSo8vZPeahROEJVn rAzXi3o8PGD7Pd+7REwuUlEHTde05pHN88VjOtwqx/f+jFhHZDcIdjCRcM5zWhStlW AAjReX3qUOXVoSZ1e5fhHll5xoFasWll7/9TzCejs98Re+no00AeksC29RAEt9R3wd 8FSlshPdO4Jaacyv+o9eDlM7xXPB2ByHUmTMhLUv/J/RryB19Y4mVpFIM1L3fHwOsm rS9hoooRzoocf/TXskhOKmqQB0Kwcu5gxwI2Yy6xsWayk0YZdf/By8AMyd1xJTJEJS /eRYAPtq5Glhg== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7310C5CFCF; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Wed, 12 Aug 2026 13:48:08 +0800 Subject: [PATCH 2/5] powerpc/spufs: fix out-of-bounds read in spufs_wbox_info_read() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260812-spufs-fixes-v1-2-449e201d9f64@outlook.com> References: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> In-Reply-To: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , David Howells , Al Viro , Jeremy Kerr , Arnd Bergmann , Paul Mackerras , Luke Browning Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Junrui Luo , Yuhao Jiang , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=2501; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=eFoKpMk5QT/Imns3PMC9qhF1gah2+vf/FhZEbtTKzCg=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrBpOua8Pz4VM9wsrv2ue81ysOzMqv2rrbC7fOq8ys XtFdRtPHO8oZWEQ42KQFVNkOV5w6ZuF7xbdLT5bkmHmsDKBDGHg4hSAiQROY2R4udnCxq4kNyFT i6U65FbbrhC2ucmL2c1n6Zam3PsgpyfCyDC/xnbN9dZ8jae2fx4um1wp9ffiP7P9mkGuzzj5rjw 4uZ8JAMIxSLI= X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo Reading a context's wbox_info file can copy up to 48 bytes past the end of an on-stack buffer to userspace. spufs_wbox_info_cnt() already returns a byte count: it multiplies the number of queued SPU inbound mailbox entries by sizeof(u32), yielding one of 0, 4, 8, 12 or 16. spufs_wbox_info_dump() uses it that way and passes the result to spufs_dump_emit() unscaled. spufs_wbox_info_read() instead multiplies it by sizeof(u32) a second time and hands the product to simple_read_from_buffer() as the length of the available data. The buffer being described is u32 data[ARRAY_SIZE(ctx->csa.spu_mailbox_data)], i.e. 16 bytes, but the value passed reaches 64. simple_read_from_buffer() clamps the transfer against that length rather than against the buffer, so once the mailbox holds two or more entries, a read reaching past offset 16 - either by requesting more than 16 bytes or by seeking there first - copies adjacent kernel stack to userspace. The mailbox occupancy is under unprivileged control. Writing to the context's wbox file drives spu_backing_wbox_write(), which lowers the free-slot count in mb_stat_R from four down to zero, and wbox_info is mode 0444 in spufs_dir_contents[], so the owner of the context can then read it back. This dates to the introduction of spufs_wbox_info_cnt(). Before that commit the local count held an entry count, for which the sizeof(u32) scaling at the call site was correct. Pass the byte count through unscaled, as spufs_wbox_info_dump() does. Fixes: 88413a6bfbbe ("powerpc/spufs: fix copy_to_user while atomic") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo --- arch/powerpc/platforms/cell/spufs/file.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platfo= rms/cell/spufs/file.c index de7494748fec..07b1755ddc3d 100644 --- a/arch/powerpc/platforms/cell/spufs/file.c +++ b/arch/powerpc/platforms/cell/spufs/file.c @@ -2028,8 +2028,7 @@ static ssize_t spufs_wbox_info_read(struct file *file= , char __user *buf, spin_unlock(&ctx->csa.register_lock); spu_release_saved(ctx); =20 - return simple_read_from_buffer(buf, len, pos, &data, - count * sizeof(u32)); + return simple_read_from_buffer(buf, len, pos, &data, count); } =20 static const struct file_operations spufs_wbox_info_fops =3D { --=20 2.51.2 From nobody Tue Sep 29 05:34:54 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 13A4526A1A4; Wed, 12 Aug 2026 05:48:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; cv=none; b=DTDrViK8aoEh/DfRITebL6N+5VBdRVwvGs7JCMxdyv2LblzJIQL2W3q0pEdPQdXN7hMuS5txIy8hQRaws7pMICZyv49jEQAhNZvey68QjLUup8QaxFLn67BhKNgnpuueZbmlu0UtMBVeVwEPW4k0Ml2n5P2x3RHUDeW4TZs30+o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; c=relaxed/simple; bh=9w+nhi98huDt+ztbUJeNG8l8k55prmsDYEDE1dmUPBg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=XCHQ4SwAHCHgC1PprjvsgA+x6Tx3h+Qu0x9eQmzy27g9p7Kz2q03/H0g9eDMqj0lbJQzY+7jvE19tbCggmsWxqxwt4duI26Gqgo7rXt7247miMe81nPmbJgsuXaJSBTUBQ7JJmKNef8I5x0WZ6noYop1tVAIL7ut94sd8tzhspI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VSct1ZPu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VSct1ZPu" Received: by smtp.kernel.org (Postfix) with ESMTPS id D1A55C2BCF4; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1786513696; bh=9w+nhi98huDt+ztbUJeNG8l8k55prmsDYEDE1dmUPBg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=VSct1ZPuUf1pjo6wxoJBm/Wp6cPJplgMzFxQttIRM0rV9/tyzZ3TcZPTIdKFxmWoQ k8HvC8lpUKYSNZGMPdyr1mSjACZfMxvR8iVTTL4h5UQ7tDmpkFMZ0ONnrQvwWPnG1j ZpiGIZScb0ZKiexf8Mv4D5DYUApGJe9amUpxpHn2QqjRwMUPC2h8Qjij9pdfIaFsWZ n4t3dvNwrXm7MlvKW16Zx6zTptlLWEhu8QEVqEXvjmyHqF5xv/g13cgDLW0mnqU08F DcDxfaistGkkUa1HODS/sgeXVS3Qic+3rdnK/eZ7AoKuIshR36rs9dBeduxlgFf5RC q7CeFLPIxNaiA== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE8C7C5B56A; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Wed, 12 Aug 2026 13:48:09 +0800 Subject: [PATCH 3/5] powerpc/spufs: take a reference on contexts pulled off the runqueue Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260812-spufs-fixes-v1-3-449e201d9f64@outlook.com> References: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> In-Reply-To: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , David Howells , Al Viro , Jeremy Kerr , Arnd Bergmann , Paul Mackerras , Luke Browning Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Junrui Luo , Yuhao Jiang , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=3301; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=T5RasOG3hMtgArux2E1H2cOe81CngMYYogn8j0wG5LU=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrBpOudSN4knvbG/uPLTXREmq+kr6q+N99XrLvJ5fF ElPP/1E+XNHKQuDGBeDrJgiy/GCS98sfLfobvHZkgwzh5UJZAgDF6cATCS4jeGvhEJDwv1fagpM j5g9w8TqbpzYmOFhyvu1OCayOmfNlagyhr+SF+6f/3pL81LH6ghF1oVpYl+Sar6e3Pxj1yPjH+e TFWtZAZhuTLk= X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo grab_runnable_context() unlinks the chosen context with __spu_del_from_rq() and returns it after dropping spu_prio->runq_lock. The runqueue holds no reference of its own =E2=80=94 __spu_add_to_rq() only= does a list_add_tail() and __spu_del_from_rq() only a list_del_init() =E2=80=94 = so the caller is left with a bare pointer. Both callers dereference it after the lock is gone: __spu_deactivate() and spusched_tick() call spu_schedule(), which starts with mutex_lock(&ctx->state_mutex). The only thing synchronizing the two sides is spu_run_fini() -> spu_del_from_rq(), which takes runq_lock. Once grab_runnable_context() has unlinked the context, that call finds ctx->rq already empty and becomes a no-op, so the owner is free to leave spu_run() and close the context directory; the resulting put_spu_context() can reach destroy_spu_context() and kfree() while the scheduler still holds the pointer. The window spans a full spu_unschedule() -> spu_unbind_context() SPU context save, and the BUG_ON(!list_empty(&ctx->rq)) in destroy_spu_context() cannot catch it because list_del_init() has already emptied ctx->rq. Fix by taking a reference in grab_runnable_context() while runq_lock is still held, where a queued context is guaranteed to be alive, and dropping it in both callers once they are done with it. This matches what find_victim() already does around its state_mutex trylock. Fixes: e65c2f6fcebb ("[POWERPC] spufs: decouple spu scheduler from spufs_sp= u_run (asynchronous scheduling)") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo --- Found by inspection; I have no Cell/PS3 hardware, so this is compile-tested only. --- arch/powerpc/platforms/cell/spufs/sched.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/cell/spufs/sched.c b/arch/powerpc/platf= orms/cell/spufs/sched.c index c52af883e01c..1b50b28cab11 100644 --- a/arch/powerpc/platforms/cell/spufs/sched.c +++ b/arch/powerpc/platforms/cell/spufs/sched.c @@ -815,6 +815,9 @@ int spu_activate(struct spu_context *ctx, unsigned long= flags) * * Remove the highest priority context on the runqueue and return it * to the caller. Returns %NULL if no runnable context was found. + * + * The context is returned with a reference held on behalf of the caller, + * which has to drop it using put_spu_context() once it is done with it. */ static struct spu_context *grab_runnable_context(int prio, int node) { @@ -830,6 +833,7 @@ static struct spu_context *grab_runnable_context(int pr= io, int node) /* XXX(hch): check for affinity here as well */ if (__node_allowed(ctx, node)) { __spu_del_from_rq(ctx); + get_spu_context(ctx); goto found; } } @@ -860,6 +864,7 @@ static int __spu_deactivate(struct spu_context *ctx, in= t force, int max_prio) interruptible */ mutex_lock(&ctx->state_mutex); } + put_spu_context(new); } } } @@ -933,8 +938,10 @@ static noinline void spusched_tick(struct spu_context = *ctx) out: spu_release(ctx); =20 - if (new) + if (new) { spu_schedule(spu, new); + put_spu_context(new); + } } =20 /** --=20 2.51.2 From nobody Tue Sep 29 05:34:54 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 2A3742E7397; Wed, 12 Aug 2026 05:48:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; cv=none; b=KeXoRQYEOJo8+h3g/D+K9tXVpGVEyVu0lxQ/ioffv47KiiqxlFTwgUTMD6Ifs4TOpsMnvUo4sjjfRAAV10Ps7c9MnzYD0/SQcGXDzq0wwWsBIwoy9pU0YrGreTr9233GMyxfFReXIiwWXcDVYhbdWEfjJM1IJoi1965dEtB0Ij8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; c=relaxed/simple; bh=FI33eKJuUW2cCOF3A+HkOrbGmEWWRPVJc9faC52wrQM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=cNsYHArf0bIp6XajDJY/zhfqsNhkJp537pqnUhR14t1zPaLtLnzF6S5b8xEBGauj+bsp2bEhZR/3WBYo6Tc2xFM1XxgkQuZ5wKhxclYtG78P1qlgvFNOR0AHxYJiWwqEsNfLh4l0V6RCb+fnAiktrHfQyXjqgv7L4V50wB+hW0w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DC+moI7u; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DC+moI7u" Received: by smtp.kernel.org (Postfix) with ESMTPS id E539BC2BCFB; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1786513696; bh=FI33eKJuUW2cCOF3A+HkOrbGmEWWRPVJc9faC52wrQM=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=DC+moI7uE1Qes4/Z0vDoanEAhVEiZ7vioNGmW17MLp/MIQy6wCuP2Y6PaGQFabn6m vG/twMaIKURhWOKFeEsBHzxJ+ASAR6BQcWn/UeY8UkY+r22cEjC5ijjW/u/7OwcF+A o7zKRv+yG0tSwdhtYaf3ljyAw3stkJWEUvhNX3rIZmN8EAFCvpzbrk3T0dJxQJlNFj 7VUh4okBaeWL9qUJor+awLs4au+7dtIm7tZRZ+3ihpgKk9jxB6My6OC9ytKn5o+Sgn DcVd14XYgNzSeCVQ25lXy0OrFiP2BsGoOQZNJfkIOijaQnS/jbOjr6tHb8Ylbhzk4n 6Z48ET+9NTMVQ== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2349C5B567; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Wed, 12 Aug 2026 13:48:10 +0800 Subject: [PATCH 4/5] powerpc/spufs: fix context state race in spu_acquire_saved() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260812-spufs-fixes-v1-4-449e201d9f64@outlook.com> References: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> In-Reply-To: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , David Howells , Al Viro , Jeremy Kerr , Arnd Bergmann , Paul Mackerras , Luke Browning Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Junrui Luo , Yuhao Jiang , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=2492; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=LOgiV6k5pQqtCquvEoYhVH8oPI1aXbE98cx2n5Jk4Uw=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrBpOOYGw9Usyiu18nAvvC4tk+pYuNA/y3Kxw4tCR0 3fYQsOdZ3eUsjCIcTHIiimyHC+49M3Cd4vuFp8tyTBzWJlAhjBwcQrARD7NYPhnL7HT8n2xe+RW wdSNS6tr+3c/U0qeJrJOymRpoub7Kq7ZjAz/hNmsXp2Jddq/pHbOl3+Prn3cN5+17URqQvtmlsr kuGomAPzFSKY= X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo spu_acquire_saved() returns with ctx->state_mutex held and the context in SPU_STATE_SAVED. It tests ctx->state once and, if the context is still running, sets SPU_SCHED_WAS_ACTIVE and calls spu_deactivate(). That path reaches __spu_deactivate(ctx, 1, MAX_PRIO), which drops state_mutex around spu_schedule() once spu_unschedule() has unbound the context, so the test result is stale by the time the function returns. A second thread reading any saved-state file of the same context can take state_mutex in that window, observe SPU_STATE_SAVED and skip its own deactivate. SPU_SCHED_WAS_ACTIVE is a single bit in ctx->sched_flags rather than a per-acquirer token, so that thread's spu_release_saved() consumes the bit and calls spu_activate(), binding the context back onto an SPU. The first thread then returns from spu_acquire_saved() with the context RUNNABLE, reads a save image the SPU is concurrently writing, and trips the BUG_ON(ctx->state !=3D SPU_STATE_SAVED) in its own spu_release_saved(), leaving state_mutex held. Fix by retesting the state after spu_deactivate() returns, which also re-sets SPU_SCHED_WAS_ACTIVE so the acquirer keeps its own reactivation token. Fixes: e65c2f6fcebb ("[POWERPC] spufs: decouple spu scheduler from spufs_sp= u_run (asynchronous scheduling)") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo --- Found by inspection; I have no Cell/PS3 hardware, so this is compile-tested only. --- arch/powerpc/platforms/cell/spufs/context.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/context.c b/arch/powerpc/pla= tforms/cell/spufs/context.c index 44377dfff1f8..2414ad9be0ae 100644 --- a/arch/powerpc/platforms/cell/spufs/context.c +++ b/arch/powerpc/platforms/cell/spufs/context.c @@ -107,7 +107,7 @@ void spu_forget(struct spu_context *ctx) * want this context to be rescheduled on release. */ mutex_lock(&ctx->state_mutex); - if (ctx->state !=3D SPU_STATE_SAVED) + while (ctx->state !=3D SPU_STATE_SAVED) spu_deactivate(ctx); =20 mm =3D ctx->owner; @@ -150,7 +150,7 @@ int spu_acquire_saved(struct spu_context *ctx) if (ret) return ret; =20 - if (ctx->state !=3D SPU_STATE_SAVED) { + while (ctx->state !=3D SPU_STATE_SAVED) { set_bit(SPU_SCHED_WAS_ACTIVE, &ctx->sched_flags); spu_deactivate(ctx); } --=20 2.51.2 From nobody Tue Sep 29 05:34:54 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 306462EB84E; Wed, 12 Aug 2026 05:48:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; cv=none; b=Y3P5WcDjcSs1xFt8aEvgJhSofzlZ4TTIv+Qjym+zZ6Gna+TjppGknwF4CDNxV9g3pn8r+SFM9du22J3UNVsZseXM5dPn+ZbsJZWldSSrrJbq2RPCQAiJ6ZEDU5hyB03JEa6K7xmWcsvpexoZHo1OcXIFOj4xkJjylxzflfxd2Cc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513697; c=relaxed/simple; bh=P8daGFXWAmT1kD9/TcyCB6sNC9wXVqWP4xIwWe1Kobs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ikq5z7gy2lI/SSv79CQUPXbNvzegA11XFAl8Fp9GMSbP+sgmP0Bb9CD2Wo+A/HA52x3ME5JOi6jkJ6Kh8SppnPYKsrcKSqgucZPFVq+hL8qATW1EB1HnPrFZBqJVdom6TuagI4YgAQ2zkDoFUxs+8DJrEPlqmab6VFJGOjlvf50= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PK/ni+Jw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PK/ni+Jw" Received: by smtp.kernel.org (Postfix) with ESMTPS id 03750C2BCFD; Wed, 12 Aug 2026 05:48:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1786513697; bh=P8daGFXWAmT1kD9/TcyCB6sNC9wXVqWP4xIwWe1Kobs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=PK/ni+JwFqGivweerGHX6F4PMlqf3oBwDQmF7GkRhM5mPFxYuN0m7NoyMrRN+xD3b 65VLPmCE9dyjpO6DVWHL5Za8QFFdtsL28heJfGcT4K+f1syGB5FkfLWvu7hoKkxEXZ JiQFow7UiTF7fYKfBNm7/K/iv2Pl6s7F1AsU0eyUXoaKVdOc6QSogDUABAqaFH7fL/ YCu3AM1Iwuk3XTM7vxhy6mtJb8C0C2k7a0wBIa3tSVaqb+OjR+FBgB9DPvBpvs5Jku d9ksx8ZGZZeoWPftGznuaiO0daOtiCtSPvwHk6onHvkb8q13tLXiC7HEGSLLSJo5nT dg/jjYhsBs2kg== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5C89C5CFEB; Wed, 12 Aug 2026 05:48:16 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Wed, 12 Aug 2026 13:48:11 +0800 Subject: [PATCH 5/5] powerpc/spufs: fix mmap_lock/state_mutex lock inversion Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260812-spufs-fixes-v1-5-449e201d9f64@outlook.com> References: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> In-Reply-To: <20260812-spufs-fixes-v1-0-449e201d9f64@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , David Howells , Al Viro , Jeremy Kerr , Arnd Bergmann , Paul Mackerras , Luke Browning Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Junrui Luo , Yuhao Jiang , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=2374; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=A766Kj+SIMmBxr8tNi5fB2Rg8hveBn1dANRK8rQSu+Q=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrBpO+XRRIc3NC47r6O/m+7zeYs7WdU9Dvn4P3qri+ LeuWVgrnL2jlIVBjItBVkyR5XjBpW8Wvlt0t/hsSYaZw8oEMoSBi1MAJrLvNSPD33kyX19tsint 9nylHb89ZypfYZi844bdeh4Za60eWpUzMPwVmLbNn+3dlKPr07u38NVPm3Io7+zN6v5E45incsZ Ofq0cAKRLSIU= X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo spufs_ps_fault() is called by the VM with mmap_lock held for read and takes ctx->state_mutex via spu_acquire(). When ctx->state is SPU_STATE_SAVED it drops mmap_lock, waits in spufs_wait() for the context to become runnable, and then re-takes mmap_lock. spufs_wait() returns with state_mutex re-acquired, and spu_release() only runs after the branch, so mmap_read_lock() is called while state_mutex is held. Every other spufs fault path takes the locks in the opposite order: spufs_mem_mmap_fault() and spufs_ps_fault() are entered with mmap_lock already held and only then take state_mutex. Three threads sharing an mm can close the cycle: one holds state_mutex and blocks in mmap_read_lock(), another holds mmap_lock for read and blocks in spu_acquire(), and a queued writer in mmap_write_lock() prevents the first down_read() from succeeding. This can result in a deadlock, and since spusched_tick() takes the same state_mutex, one wedged context also stalls SPU scheduling for every other context on the node. Fix by calling spu_release() before re-taking mmap_lock and jumping to the existing refault path, which drops the reference taken earlier in the function and returns VM_FAULT_NOPAGE as before. Fixes: 33bfd7a73861 ("[POWERPC] spufs: block fault handlers in spu_acquire_= runnable") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo --- Found by inspection; I have no Cell/PS3 hardware, so this is compile-tested only. --- arch/powerpc/platforms/cell/spufs/file.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platfo= rms/cell/spufs/file.c index 07b1755ddc3d..d479c956506d 100644 --- a/arch/powerpc/platforms/cell/spufs/file.c +++ b/arch/powerpc/platforms/cell/spufs/file.c @@ -349,7 +349,10 @@ static vm_fault_t spufs_ps_fault(struct vm_fault *vmf, spu_context_nospu_trace(spufs_ps_fault__sleep, ctx); err =3D spufs_wait(ctx->run_wq, ctx->state =3D=3D SPU_STATE_RUNNABLE); spu_context_trace(spufs_ps_fault__wake, ctx, ctx->spu); + if (!err) + spu_release(ctx); mmap_read_lock(current->mm); + goto refault; } else { area =3D ctx->spu->problem_phys + ps_offs; ret =3D vmf_insert_pfn(vmf->vma, vmf->address, --=20 2.51.2