nuxfoundation.org header.b=C3zoHHBY; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE86CC4CEF7; Wed, 4 Feb 2026 14:43:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216205; bh=KQScA0WwwFdVH5i3prfIJaZY/Uay5WbGnkxYJqERFdI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C3zoHHBYXqlWxDb5ff6jB4IF338+R9igfwHOaRlDcY3d4UKA3wyi41nRY3Mmr7FOK sumi+6nEXZ+TOxyYxCmQsBCDQO+p7QI8BHOto/BJfZqIoTDziynbB9vumT4hElZBFQ ypAeuNGKnY6sz194WvkWb3smiy/6xJK9SJ0kei74= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Benjamin Tissoires , Salvatore Bonaccorso Subject: [PATCH 5.10 019/161] HID: usbhid: paper over wrong bNumDescriptor field Date: Wed, 4 Feb 2026 15:38:02 +0100 Message-ID: <20260204143852.455385080@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260204143851.755002596@linuxfoundation.org> References: <20260204143851.755002596@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Benjamin Tissoires commit f28beb69c51517aec7067dfb2074e7c751542384 upstream. Some faulty devices (ZWO EFWmini) have a wrong optional HID class descriptor count compared to the provided length. Given that we plainly ignore those optional descriptor, we can attempt to fix the provided number so we do not lock out those devices. Signed-off-by: Benjamin Tissoires Cc: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman --- drivers/hid/usbhid/hid-core.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) --- a/drivers/hid/usbhid/hid-core.c +++ b/drivers/hid/usbhid/hid-core.c @@ -985,6 +985,7 @@ static int usbhid_parse(struct hid_devic struct usb_device *dev = interface_to_usbdev (intf); struct hid_descriptor *hdesc; struct hid_class_descriptor *hcdesc; + __u8 fixed_opt_descriptors_size; u32 quirks = 0; unsigned int rsize = 0; char *rdesc; @@ -1015,7 +1016,21 @@ static int usbhid_parse(struct hid_devic (hdesc->bNumDescriptors - 1) * sizeof(*hcdesc)) { dbg_hid("hid descriptor invalid, bLen=%hhu bNum=%hhu\n", hdesc->bLength, hdesc->bNumDescriptors); - return -EINVAL; + + /* + * Some devices may expose a wrong number of descriptors compared + * to the provided length. + * However, we ignore the optional hid class descriptors entirely + * so we can safely recompute the proper field. + */ + if (hdesc->bLength >= sizeof(*hdesc)) { + fixed_opt_descriptors_size = hdesc->bLength - sizeof(*hdesc); + + hid_warn(intf, "fixing wrong optional hid class descriptors count\n"); + hdesc->bNumDescriptors = fixed_opt_descriptors_size / sizeof(*hcdesc) + 1; + } else { + return -EINVAL; + } } hid->version = le16_to_cpu(hdesc->bcdHID); From - Wed Feb 04 14:43:43 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id oGiTJxRbg2m/wBMAYBR5ng (envelope-from ) for ; Wed, 04 Feb 2026 14:43:32 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Wed, 04 Feb 2026 14:43:32 +0000 Received: from sto.lore.kernel.org ([172.232.135.74]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vne6O-000000062qK-1DrH for hi@josie.lol; Wed, 04 Feb 2026 14:43:32 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id C69DC3006682 for ; Wed, 4 Feb 2026 14:43:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 825E440758D; Wed, 4 Feb 2026 14:43:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="wF76QtGo" X-Original-To: stable@vger.kernel.org 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 600BB280A3B; Wed, 4 Feb 2026 14:43:28 +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=1770216208; cv=none; b=UmzsXFPlFbYPUGPkFvgGD/DoczbAriAsj/zRXE1o292+dq6v31bgMSYuJ5e+uO8BlErOZvc/MquHY06ik0h7N3ovD6/3SwWHB2pUjMQ8mBQOp5we6QySPtUw74RowPxZ35LkriZfHp7CHKJe/+gKWxzmUrzSi1NyjUmrrVbZ8WE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770216208; c=relaxed/simple; bh=VvtFOLHLJiRka/Xbo7FwGM2NZiLUilW1M40IUJ3+6UA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=D7cRqup5iyPDc0mJYJGDsfe5EYWMNjzHZvqMsgYc5GcOa78yalMwLLG0aYMBDtf7YLTsGLhqGgUlNendNtNhhBqC0+iRJa0tPhZgAmhplQ97O7AjlePn0bq5i2cxk6hI913Rz3+CnmEuyXnwgqIvtviK+Trx0ITsG/t4A3dGEqc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=wF76QtGo; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2EADC4CEF7; Wed, 4 Feb 2026 14:43:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216208; bh=VvtFOLHLJiRka/Xbo7FwGM2NZiLUilW1M40IUJ3+6UA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wF76QtGo1D6rgi8U+7dAJcXlrcOHVvkv2pJZUBQQg51C7pbaAUQYj/EQ+Bi3yDfev 76UXztVY0bWLEYQpP8fYy/u0k+l3BQHDZR+MLInUDlsu+ptiAPG5jSF4wKVmrC53DO l/0QX41Xns/HX7dOQZwh61Ek8fUOmElf+hKDHuc8= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Maurizio Lombardi , Sagi Grimberg , Keith Busch , Sasha Levin Subject: [PATCH 5.10 002/161] nvmet-tcp: remove boilerplate code Date: Wed, 4 Feb 2026 15:37:45 +0100 Message-ID: <20260204143851.848546164@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260204143851.755002596@linuxfoundation.org> References: <20260204143851.755002596@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linuxfoundation.org] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.232.135.74 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Maurizio Lombardi [ Upstream commit 75011bd0f9c55db523242f9f9a0b0b826165f14b ] Simplify the nvmet_tcp_handle_h2c_data_pdu() function by removing boilerplate code. Signed-off-by: Maurizio Lombardi Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Stable-dep-of: 32b63acd78f5 ("nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec") Signed-off-by: Sasha Levin --- drivers/nvme/target/tcp.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c index 6019eee1f9bdf..d7b368102ad9a 100644 --- a/drivers/nvme/target/tcp.c +++ b/drivers/nvme/target/tcp.c @@ -933,8 +933,7 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue) if (unlikely(data->ttag >= queue->nr_cmds)) { pr_err("queue %d: received out of bound ttag %u, nr_cmds %u\n", queue->idx, data->ttag, queue->nr_cmds); - nvmet_tcp_fatal_error(queue); - return -EPROTO; + goto err_proto; } cmd = &queue->cmds[data->ttag]; } else { @@ -945,9 +944,7 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue) pr_err("ttag %u unexpected data offset %u (expected %u)\n", data->ttag, le32_to_cpu(data->data_offset), cmd->rbytes_done); - /* FIXME: use path and transport errors */ - nvmet_tcp_fatal_error(queue); - return -EPROTO; + goto err_proto; } exp_data_len = le32_to_cpu(data->hdr.plen) - @@ -960,9 +957,7 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue) cmd->pdu_len == 0 || cmd->pdu_len > NVMET_TCP_MAXH2CDATA)) { pr_err("H2CData PDU len %u is invalid\n", cmd->pdu_len); - /* FIXME: use proper transport errors */ - nvmet_tcp_fatal_error(queue); - return -EPROTO; + goto err_proto; } cmd->pdu_recv = 0; nvmet_tcp_map_pdu_iovec(cmd); @@ -970,6 +965,11 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue) queue->rcv_state = NVMET_TCP_RECV_DATA; return 0; + +err_proto: + /* FIXME: use proper transport errors */ + nvmet_tcp_fatal_error(queue); + return -EPROTO; } static int nvmet_tcp_done_recv_pdu(struct nvmet_tcp_queue *queue) -- 2.51.0 From - Wed Feb 04 14:43:43 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id eJrtJxRbg2kijhMAYBR5ng (envelope-from ) for ; Wed, 04 Feb 2026 14:43:32 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Wed, 04 Feb 2026 14:43:32 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vne6O-000000062qh-1ddX for hi@josie.lol; Wed, 04 Feb 2026 14:43:32 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 53D4430097D0 for ; Wed, 4 Feb 2026 14:43:01 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A164040758D; Wed, 4 Feb 2026 14:42:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="oUKj0sBn" X-Original-To: stable@vger.kernel.org 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 7ED501EA84; Wed, 4 Feb 2026 14:42:59 +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=1770216179; cv=none; b=na8xNp3zd9BTRptSV/NwLDCXvHQzfprfvp+Mh8N4IrV8d/0qVjd2LbwMhgWvAIpKZ8vbf2STz/ueIdO4jvVekWy4xkQlvGR4nGtw29YUC5CqVy/97l+PIOV0g8nJ11SlXxLPeqJ30GlPDQPghvQpGdnSTX0uzsfgQs6oDmlDisU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770216179; c=relaxed/simple; bh=rhDF6y1K2DXFq7nyyTCSM8GXTMo6w8k9Lfsw8jE5MZs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sTwMOlWVqjVpLpXr/GYKPLGU8k0bmF3R9riIan8Y7txCVATag38PNUdo7mtgrcjFT/vRV8zEvy4+y8x/f8eZYYTEtiRxV6YAwK7qgaB0P46rMvuYXNq9uUKrUUijQpzOvdqXTCLmvtocJjJirV31d5zRBivmWTHFGKuVjEGydfA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=oUKj0sBn; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90E83C116C6; Wed, 4 Feb 2026 14:42:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216179; bh=rhDF6y1K2DXFq7nyyTCSM8GXTMo6w8k9Lfsw8jE5MZs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oUKj0sBnMEiP6CVvVoB9tfrpYBH+dTtfjfQSPj+MJFM4mNPAZ/Kikx8rPwWYgWZAY 2XVFJ2Gog9X/pqQ0vQkzAmLZujrRDWdgxFaBbNApzOxuIBhehxsKo0T6R24kGQ5OIh Qwn3IG0qbYBEZEW6p+gy9aV5o/O0WUKkeELWJjEA= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, syzbot+07f3f38f723c335f106d@syzkaller.appspotmail.com, Eric Dumazet , Jamal Hadi Salim , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.10 011/161] net/sched: sch_qfq: do not free existing class in qfq_change_class() Date: Wed, 4 Feb 2026 15:37:54 +0100 Message-ID: <20260204143852.169872461@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260204143851.755002596@linuxfoundation.org> References: <20260204143851.755002596@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet [ Upstream commit 3879cffd9d07aa0377c4b8835c4f64b4fb24ac78 ] Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF. Fixes: 462dbc9101ac ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost") Reported-by: syzbot+07f3f38f723c335f106d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6965351d.050a0220.eaf7.00c5.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260112175656.17605-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- net/sched/sch_qfq.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c index 34a6c4ec9a157..9751de2d95e78 100644 --- a/net/sched/sch_qfq.c +++ b/net/sched/sch_qfq.c @@ -532,8 +532,10 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid, return 0; destroy_class: - qdisc_put(cl->qdisc); - kfree(cl); + if (!existing) { + qdisc_put(cl->qdisc); + kfree(cl); + } return err; } -- 2.51.0 From - Wed Feb 04 14:43:43 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id sIePGhtbg2kijhMAYBR5ng (envelope-from ) for ; Wed, 04 Feb 2026 14:43:39 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Wed, 04 Feb 2026 14:43:39 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vne6V-0000000630x-0bHr for hi@josie.lol; Wed, 04 Feb 2026 14:43:39 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 70F3B300DF6C for ; Wed, 4 Feb 2026 14:43:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D5170345CA5; Wed, 4 Feb 2026 14:43:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="cLy0wuW2" X-Original-To: stable@vger.kernel.org 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 B3143280A3B; Wed, 4 Feb 2026 14:43:05 +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=1770216185; cv=none; b=J4r410DgalYnYvrJf9Wsgm19ewKPuP0IEHhb6x8YWtclpiHfHuhYhJfxSenq+D/vQPuBhiFCVeZxFfc3SOzSbbXER9xsYwkigDOcJ5R1ASgwwy1PZEWrc6L+G9ZdhHEVwvT20mur92UmlX+igCm+G8lYD7j37jE4zEMNwGT8XYM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770216185; c=relaxed/simple; bh=izc3osVD0R35hxaTUjCovLcHFR1YrpcWcLEH5uuwbqs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QMDqOWw9aC2Uy0hAszvYW88pOwPW/O4pce9QD2vpU/TTsINcD4lR6Uz96mOoQfAJKD1fFA9L9a3ovd0Tnx4dfTmB064UUxWxZj9pKCidxV1YJQ/yH8M8E5GI4BEHLCzt07SnOZpjyzEbXgI2ANsd/B1XK/0qhn3VnElrc0a3btU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=cLy0wuW2; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A97DC4CEF7; Wed, 4 Feb 2026 14:43:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216185; bh=izc3osVD0R35hxaTUjCovLcHFR1YrpcWcLEH5uuwbqs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cLy0wuW2Wq266l/0fBlEE+U6in53TLaoeXcJIr9oiys5DCqsFYo/cyoyoh+M3s3eh RAO1w+krIyZuhTWfMqsNxo11xdfJrBvSXJvD4LygXYasudH9fTFLA5tE/yiNH+4YHI 3DUFpclrDRIH+YRRsH4yi/hHLV0AbyfAtx1INItI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Bagas Sanjaya , Thomas Graf , "David S. Miller" , Andrew Morton , Sasha Levin Subject: [PATCH 5.10 013/161] textsearch: describe @list member in ts_ops search Date: Wed, 4 Feb 2026 15:37:56 +0100 Message-ID: <20260204143852.242377476@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260204143851.755002596@linuxfoundation.org> References: <20260204143851.755002596@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linuxfoundation.org] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Bagas Sanjaya [ Upstream commit f26528478bb102c28e7ac0cbfc8ec8185afdafc7 ] Sphinx reports kernel-doc warning: WARNING: ./include/linux/textsearch.h:49 struct member 'list' not described in 'ts_ops' Describe @list member to fix it. Link: https://lkml.kernel.org/r/20251219014006.16328-4-bagasdotme@gmail.com Fixes: 2de4ff7bd658 ("[LIB]: Textsearch infrastructure.") Signed-off-by: Bagas Sanjaya Cc: Thomas Graf Cc: "David S. Miller" Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin --- include/linux/textsearch.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/textsearch.h b/include/linux/textsearch.h index 13770cfe33ad8..1389959b68422 100644 --- a/include/linux/textsearch.h +++ b/include/linux/textsearch.h @@ -35,6 +35,7 @@ struct ts_state * @get_pattern: return head of pattern * @get_pattern_len: return length of pattern * @owner: module reference to algorithm + * @list: list to search */ struct ts_ops { -- 2.51.0 From - Wed Feb 04 14:43:47 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id CPZaJB1bg2kijhMAYBR5ng (envelope-from ) for ; Wed, 04 Feb 2026 14:43:41 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Wed, 04 Feb 2026 14:43:41 +0000 Received: from sto.lore.kernel.org ([172.232.135.74]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vne6X-0000000635i-0ZFE for hi@josie.lol; Wed, 04 Feb 2026 14:43:41 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id DA25E3004F12 for ; Wed, 4 Feb 2026 14:43:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1C27F345CA5; Wed, 4 Feb 2026 14:43:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="KgBKwNIb" X-Original-To: stable@vger.kernel.org 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 ED51A280A3B; Wed, 4 Feb 2026 14:43:37 +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=1770216218; cv=none; b=FKI1dd65slnbdOYdtM8lYn+S70YDO1CHNATI/pHM1Rkbpw2/uZ2DbYwPWts6guAEVG04wmwjC2r/T6k7mueXQjEp0mwcpKPuSUEMW6HyO2UYoHezhcYjYcfUnVKgRHskM39DcbQClqmeRdoog/me18F+AkX6IoO/iPSowdRq4d4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770216218; c=relaxed/simple; bh=ryUG+DAngtHih/4Xm6jvNj4NRYvcOjnG5PlIAHqNBg4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=LBMVBEDlTH1XquqHUCchhwrc1QY5w5psVFQ+P6BnttURTK6eO5ypIZuV+oobjmcYg86E8js4DfeXS9qE+Wz3+2DhTIWk0nEX1yDWc4CauHJ7WBcQccaAg3JrhdeowL5Yazhp28gPoQieaSI8+sthfrfvxs+BHQwx4tPVNAt7qug= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=KgBKwNIb; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F716C4CEF7; Wed, 4 Feb 2026 14:43:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216217; bh=ryUG+DAngtHih/4Xm6jvNj4NRYvcOjnG5PlIAHqNBg4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KgBKwNIbpHrYHkjwTlk3oDKNpBgWfJwdZ5g6H9/fzehiUELOsp0mRew950MKmwIbx VRI4AYlreFo22Pvfw4kbDI0JY9s57fRuESpq6K93+YVoaG4IrzMZ8DDYsMEp5HHSEG AeOYAztT/ZpP9yjOTI9HxzE9ut3kyfv7FFTXvero= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Luca Ceresoli , =?UTF-8?q?Th=C3=A9o=20Lebrun?= , Vinod Koul Subject: [PATCH 5.10 022/161] phy: rockchip: inno-usb2: fix communication disruption in gadget mode Date: Wed, 4 Feb 2026 15:38:05 +0100 Message-ID: <20260204143852.563376077@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260204143851.755002596@linuxfoundation.org> References: <20260204143851.755002596@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linuxfoundation.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Luca Ceresoli commit 7d8f725b79e35fa47e42c88716aad8711e1168d8 upstream. When the OTG USB port is used to power to SoC, configured as peripheral and used in gadget mode, communication stops without notice about 6 seconds after the gadget is configured and enumerated. The problem was observed on a Radxa Rock Pi S board, which can only be powered by the only USB-C connector. That connector is the only one usable in gadget mode. This implies the USB cable is connected from before boot and never disconnects while the kernel runs. The related code flow in the PHY driver code can be summarized as: * the first time chg_detect_work starts (6 seconds after gadget is configured and enumerated) -> rockchip_chg_detect_work(): if chg_state is UNDEFINED: property_enable(base, &rphy->phy_cfg->chg_det.opmode, false); [Y] * rockchip_chg_detect_work() changes state and re-triggers itself a few times until it reaches the DETECTED state: -> rockchip_chg_detect_work(): if chg_state is DETECTED: property_enable(base, &rphy->phy_cfg->chg_det.opmode, true); [Z] At [Y] all existing communications stop. E.g. using a CDC serial gadget, the /dev/tty* devices are still present on both host and device, but no data is transferred anymore. The later call with a 'true' argument at [Z] does not restore it. Due to the lack of documentation, what chg_det.opmode does exactly is not clear, however by code inspection it seems reasonable that is disables something needed to keep the communication working, and testing proves that disabling these lines lets gadget mode keep working. So prevent changes to chg_det.opmode when there is a cable connected (VBUS present). Fixes: 98898f3bc83c ("phy: rockchip-inno-usb2: support otg-port for rk3399") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/lkml/20250414185458.7767aabc@booty/ Signed-off-by: Luca Ceresoli Reviewed-by: Théo Lebrun Link: https://patch.msgid.link/20251127-rk3308-fix-usb-gadget-phy-disconnect-v2-2-dac8a02cd2ca@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman --- drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c @@ -699,7 +699,8 @@ static void rockchip_chg_detect_work(str if (!rport->suspended) rockchip_usb2phy_power_off(rport->phy); /* put the controller in non-driving mode */ - property_enable(base, &rphy->phy_cfg->chg_det.opmode, false); + if (!vbus_attach) + property_enable(base, &rphy->phy_cfg->chg_det.opmode, false); /* Start DCD processing stage 1 */ rockchip_chg_enable_dcd(rphy, true); rphy->chg_state = USB_CHG_STATE_WAIT_FOR_DCD; @@ -763,7 +764,8 @@ static void rockchip_chg_detect_work(str fallthrough; case USB_CHG_STATE_DETECTED: /* put the controller in normal mode */ - property_enable(base, &rphy->phy_cfg->chg_det.opmode, true); + if (!vbus_attach) + property_enable(base, &rphy->phy_cfg->chg_det.opmode, true); rockchip_usb2phy_otg_sm_work(&rport->otg_sm_work.work); dev_dbg(&rport->phy->dev, "charger = %s\n", chg_to_string(rphy->chg_type)); From - Wed Feb 04 14:43:47 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 0GpDOx1bg2nJ9RMAYBR5ng (envelope-from ) for ; Wed, 04 Feb 2026 14:43:41 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Wed, 04 Feb 2026 14:43:42 +0000 Received: from sin.lore.kernel.org ([104.64.211.4]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vne6W-0000000630e-4Bjq for hi@josie.lol; Wed, 04 Feb 2026 14:43:41 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with ESMTP id DC7093004054 for ; Wed, 4 Feb 2026 14:43:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F0C69345CA5; Wed, 4 Feb 2026 14:43:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Bax34qkY" X-Original-To: stable@vger.kernel.org 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 CE6B7280A3B; Wed, 4 Feb 2026 14:43:34 +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=1770216214; cv=none; b=KCUqi7J9E0Lx/LWI0Gt4sGgl30rA16+roSrdIQrNSxDvow3Ua9UkMFOMu4sKXnPSPIowLrs4Zt5uXUktlCOkLbeyUP/pNXkdvvXWKbI7CZ82jsInmuq2LUMvEzk+f6MNRAHE7gRivPo8a9uhpndMwHf5qzVZLTxeMUs+tjhOK54= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770216214; c=relaxed/simple; bh=O1H2aEhRpmk2b+Iwa3mE2BXPEom8t/i6gtL3oIfRA+c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jsCYfIy+C+z1PtHSNgzhZzgCRjsTMT8qVtXEO9rh+HRiNn93UIpkXC1G8ZQwI97E89xgfc8E6p1V5xyI8ZJrfj/2mzR8BpupsCoWE9HQLCjHZ+CvW7HjjxxRguQwKsWUopbtN3tAs9Or0sgmSoWInt2UFb7qki46TeXewMmhiTQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Bax34qkY; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4113C4CEF7; Wed, 4 Feb 2026 14:43:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216214; bh=O1H2aEhRpmk2b+Iwa3mE2BXPEom8t/i6gtL3oIfRA+c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Bax34qkYZHl0fUoAS9jiqiOzeM+MMQ53CbYdX0qw2wnKlv8CraPL473M9aeaXf6t/ SHdTVfnbuKhygyuL9dDC1CNN5kCAQRCDKNN/QvS3V3yGfEou+lI2bnvvJV60s5tMWQ aV0n878q694S57Zt71cbCf07psM9xjG/A+D0V7Uc= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, syzbot , Tetsuo Handa , Oleksij Rempel , Marc Kleine-Budde Subject: [PATCH 5.10 021/161] net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts Date: Wed, 4 Feb 2026 15:38:04 +0100 Message-ID: <20260204143852.527608936@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260204143851.755002596@linuxfoundation.org> References: <20260204143851.755002596@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linuxfoundation.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tetsuo Handa commit 1809c82aa073a11b7d335ae932d81ce51a588a4a upstream. Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Signed-off-by: Tetsuo Handa Tested-by: Oleksij Rempel Acked-by: Oleksij Rempel Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://patch.msgid.link/b1212653-8fa1-44e1-be9d-12f950fb3a07@I-love.SAKURA.ne.jp Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman --- net/can/j1939/transport.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/net/can/j1939/transport.c +++ b/net/can/j1939/transport.c @@ -1680,8 +1680,16 @@ static int j1939_xtp_rx_rts_session_acti j1939_session_timers_cancel(session); j1939_session_cancel(session, J1939_XTP_ABORT_BUSY); - if (session->transmission) + if (session->transmission) { j1939_session_deactivate_activate_next(session); + } else if (session->state == J1939_SESSION_WAITING_ABORT) { + /* Force deactivation for the receiver. + * If we rely on the timer starting in j1939_session_cancel, + * a second RTS call here will cancel that timer and fail + * to restart it because the state is already WAITING_ABORT. + */ + j1939_session_deactivate_activate_next(session); + } return -EBUSY; } From - Wed Feb 04 14:43:47 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id aMkmKh9bg2lKhhQAYBR5ng (envelope-from ) for ; Wed, 04 Feb 2026 14:43:43 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Wed, 04 Feb 2026 14:43:43 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vne6Z-0000000637H-1HbD for hi@josie.lol; Wed, 04 Feb 2026 14:43:43 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 4B039300F5E6 for ; Wed, 4 Feb 2026 14:43:10 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9757140758D; Wed, 4 Feb 2026 14:43:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="g9J0Ur/C" X-Original-To: stable@vger.kernel.org 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 73EF61EA84; Wed, 4 Feb 2026 14:43:09 +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=1770216189; cv=none; b=U8IdSC98SCwOyVHkBqYrnkEuK0+AfhRisgsobxbPUNJ3twrpeqEWuB9DnO1P5XCdaROGwa5UVAD1maIidUDO9qzVEN4ZmaLlh2BRrLPCxCp1jfV42NpBLte7gv+00xyAnf+RrYMW+ZhoZKtS+yFTPbaocdvVRqyNLrqDUftBAHw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770216189; c=relaxed/simple; bh=UpX8iYCwAEcJi/Gw4V1IZ1WN1gbDXzRFgwVLzjZzw7I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BfPIn4Ow0ARVs6kMoPP5YfrueAR/QJfE+gD0wrpHRqPO/E++Pn3v9tp4ga12qiTQezxvs7DqWKs3co/airjzcPjuKjUy3bB99icQL46yVcr7OFc2Cm9rZ8qePKVwAnPK4KhFt4dHGgPBoxNwjY8kC8lTt0Cq0UDR5FGxgG9iMHE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=g9J0Ur/C; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97959C4CEF7; Wed, 4 Feb 2026 14:43:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216189; bh=UpX8iYCwAEcJi/Gw4V1IZ1WN1gbDXzRFgwVLzjZzw7I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g9J0Ur/C7crFYBh3AeW1pT6LouShRVHmZNvo2BUfJu+VOqC9PxfntlZUDu/cZ7uUs oT8tvE/7CLvvuoi+Io/hixV1qezuOE+ZUr8+i/HsmmhvJpWokA3wkYKQvfpGqtsX4u zdwlJCudeIAkrek35DhiFaSCggIRRyPp4Cg6NRbo= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Sheetal , Thierry Reding , Vinod Koul , Sasha Levin Subject: [PATCH 5.10 014/161] dmaengine: tegra-adma: Fix use-after-free Date: Wed, 4 Feb 2026 15:37:57 +0100 Message-ID: <20260204143852.278622273@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260204143851.755002596@linuxfoundation.org> References: <20260204143851.755002596@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sheetal [ Upstream commit 2efd07a7c36949e6fa36a69183df24d368bf9e96 ] A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegra_adma_terminate_all() before the vchan completion tasklet finishes accessing it. The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memory Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchan_complete() runs. Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors. Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0 [ 337.427562] Call trace: [ 337.427564] dump_backtrace+0x0/0x320 [ 337.427571] show_stack+0x20/0x30 [ 337.427575] dump_stack_lvl+0x68/0x84 [ 337.427584] print_address_description.constprop.0+0x74/0x2b8 [ 337.427590] kasan_report+0x1f4/0x210 [ 337.427598] __asan_load8+0xa0/0xd0 [ 337.427603] vchan_complete+0x124/0x3b0 [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0 [ 337.427617] tasklet_action+0x30/0x40 [ 337.427623] __do_softirq+0x1a0/0x5c4 [ 337.427628] irq_exit+0x110/0x140 [ 337.427633] handle_domain_irq+0xa4/0xe0 [ 337.427640] gic_handle_irq+0x64/0x160 [ 337.427644] call_on_irq_stack+0x20/0x4c [ 337.427649] do_interrupt_handler+0x7c/0x90 [ 337.427654] el1_interrupt+0x30/0x80 [ 337.427659] el1h_64_irq_handler+0x18/0x30 [ 337.427663] el1h_64_irq+0x7c/0x80 [ 337.427667] cpuidle_enter_state+0xe4/0x540 [ 337.427674] cpuidle_enter+0x54/0x80 [ 337.427679] do_idle+0x2e0/0x380 [ 337.427685] cpu_startup_entry+0x2c/0x70 [ 337.427690] rest_init+0x114/0x130 [ 337.427695] arch_call_rest_init+0x18/0x24 [ 337.427702] start_kernel+0x380/0x3b4 [ 337.427706] __primary_switched+0xc0/0xc8 Fixes: f46b195799b5 ("dmaengine: tegra-adma: Add support for Tegra210 ADMA") Signed-off-by: Sheetal Acked-by: Thierry Reding Link: https://patch.msgid.link/20251110142445.3842036-1-sheetal@nvidia.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin --- drivers/dma/tegra210-adma.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c index d84010c2e4bf1..bcd1deb082615 100644 --- a/drivers/dma/tegra210-adma.c +++ b/drivers/dma/tegra210-adma.c @@ -344,10 +344,17 @@ static void tegra_adma_stop(struct tegra_adma_chan *tdc) return; } - kfree(tdc->desc); + vchan_terminate_vdesc(&tdc->desc->vd); tdc->desc = NULL; } +static void tegra_adma_synchronize(struct dma_chan *dc) +{ + struct tegra_adma_chan *tdc = to_tegra_adma_chan(dc); + + vchan_synchronize(&tdc->vc); +} + static void tegra_adma_start(struct tegra_adma_chan *tdc) { struct virt_dma_desc *vd = vchan_next_desc(&tdc->vc); @@ -893,6 +900,7 @@ static int tegra_adma_probe(struct platform_device *pdev) tdma->dma_dev.device_config = tegra_adma_slave_config; tdma->dma_dev.device_tx_status = tegra_adma_tx_status; tdma->dma_dev.device_terminate_all = tegra_adma_terminate_all; + tdma->dma_dev.device_synchronize = tegra_adma_synchronize; tdma->dma_dev.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES); tdma->dma_dev.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES); tdma->dma_dev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV); -- 2.51.0 From - Wed Feb 04 14:43:52 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 8D8zBiRbg2lKhhQAYBR5ng (envelope-from ) for ; Wed, 04 Feb 2026 14:43:48 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Wed, 04 Feb 2026 14:43:48 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vne6d-000000063Gd-3NAB for hi@josie.lol; Wed, 04 Feb 2026 14:43:48 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 29FFF301052E for ; Wed, 4 Feb 2026 14:43:14 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CEB6D280A3B; Wed, 4 Feb 2026 14:43:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="mZWnzYJn" X-Original-To: stable@vger.kernel.org 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 AC6591EA84; Wed, 4 Feb 2026 14:43:12 +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=1770216192; cv=none; b=JPfBhLIQFwXkic8quTM6NHiE9HyFQ3SyFp/+1tO/DD4hWsWRzdwICBuJUnsx5Wr36lLS9ChKZZwUDGZ2B3616DKItbqV1qHpIOLSd7e3ua3wBkw2xjuHMyuu+88Mb07M2joNsBsdnXZILeTEO7hkls+urTLbjLaBFIMwnwRAC4w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770216192; c=relaxed/simple; bh=5XsBD9a8thYfI+iHS224mgUk+7f323eD2TOA+Q6tl0Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bMReRikFke2hiEdlIqo5fUIviLhfxqdr8kxS8PZ0FvQ0O0lW8JkFTh+oFv1UTRN5WsD4AVegq44iL8fhkpCfd6MG1IYMP4Rq7z4NlUGpT9h7zpz8PgkrrcTkqPjB+JHw+vgSJBLOM76vL1q/zmIRTrBCppLFZPwd/lgBHUK728M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=mZWnzYJn; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03DFDC4CEF7; Wed, 4 Feb 2026 14:43:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216192; bh=5XsBD9a8thYfI+iHS224mgUk+7f323eD2TOA+Q6tl0Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mZWnzYJnKgNHStPXHG9xR/AwHRv/dS6L40SNuGo6iWuCjnIN9ADfMJAMiMVMePSl1 09fBNugpEVVX3NOiRLzKD11ISyXL2DvpDDBkDoK8Y1liU6YEoa2LFPce0c0x9iPEVt 1t/UptJ7rfBRkiBnRI+CeMqkHh63pp/AY9PVzuNE= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Suraj Gupta , Radhey Shyam Pandey , Folker Schwesinger , Vinod Koul , Sasha Levin Subject: [PATCH 5.10 015/161] dmaengine: xilinx_dma: Fix uninitialized addr_width when "xlnx,addrwidth" property is missing Date: Wed, 4 Feb 2026 15:37:58 +0100 Message-ID: <20260204143852.314173736@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260204143851.755002596@linuxfoundation.org> References: <20260204143851.755002596@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linuxfoundation.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Suraj Gupta [ Upstream commit c0732fe78728718c853ef8e7af5bbb05262acbd1 ] When device tree lacks optional "xlnx,addrwidth" property, the addr_width variable remained uninitialized with garbage values, causing incorrect DMA mask configuration and subsequent probe failure. The fix ensures a fallback to the default 32-bit address width when this property is missing. Signed-off-by: Suraj Gupta Fixes: b72db4005fe4 ("dmaengine: vdma: Add 64 bit addressing support to the driver") Reviewed-by: Radhey Shyam Pandey Reviewed-by: Folker Schwesinger Link: https://patch.msgid.link/20251021183006.3434495-1-suraj.gupta2@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin --- drivers/dma/xilinx/xilinx_dma.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c index 3ecf0109af2ba..12e9ba5b114db 100644 --- a/drivers/dma/xilinx/xilinx_dma.c +++ b/drivers/dma/xilinx/xilinx_dma.c @@ -128,6 +128,7 @@ #define XILINX_MCDMA_MAX_CHANS_PER_DEVICE 0x20 #define XILINX_DMA_MAX_CHANS_PER_DEVICE 0x2 #define XILINX_CDMA_MAX_CHANS_PER_DEVICE 0x1 +#define XILINX_DMA_DFAULT_ADDRWIDTH 0x20 #define XILINX_DMA_DMAXR_ALL_IRQ_MASK \ (XILINX_DMA_DMASR_FRM_CNT_IRQ | \ @@ -2996,7 +2997,7 @@ static int xilinx_dma_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; struct xilinx_dma_device *xdev; struct device_node *child, *np = pdev->dev.of_node; - u32 num_frames, addr_width, len_width; + u32 num_frames, addr_width = XILINX_DMA_DFAULT_ADDRWIDTH, len_width; int i, err; /* Allocate and initialize the DMA engine structure */ @@ -3065,7 +3066,9 @@ static int xilinx_dma_probe(struct platform_device *pdev) err = of_property_read_u32(node, "xlnx,addrwidth", &addr_width); if (err < 0) - dev_warn(xdev->dev, "missing xlnx,addrwidth property\n"); + dev_warn(xdev->dev, + "missing xlnx,addrwidth property, using default value %d\n", + XILINX_DMA_DFAULT_ADDRWIDTH); if (addr_width > 32) xdev->ext_addr = true; -- 2.51.0 From - Wed Feb 04 14:43:56 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id mId4Fydbg2lchRMAYBR5ng (envelope-from ) for ; Wed, 04 Feb 2026 14:43:51 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Wed, 04 Feb 2026 14:43:51 +0000 Received: from sto.lore.kernel.org ([172.232.135.74]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vne6g-000000063Lw-4A78 for hi@josie.lol; Wed, 04 Feb 2026 14:43:51 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id B6E453004637 for ; Wed, 4 Feb 2026 14:43:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2047F40758D; Wed, 4 Feb 2026 14:43:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="PL1vwJFB" X-Original-To: stable@vger.kernel.org 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 F1723280A3B; Wed, 4 Feb 2026 14:43:47 +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=1770216228; cv=none; b=U2wkicP/uIeViOCxN8tjYFGeV0CjBgTKoELsbPUWRba7rf/atRUqughJgA5KeNLiy3d2LrKMmkrRiIfjqJuGQ4XxsKUK97pUbH/HHc7xfRLE8sRKzsAs+7ItrJmNxuESpMU7kgiaXdcG/lRZVdKAXXNqoyS+NYfK6g2GOi5E7WQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770216228; c=relaxed/simple; bh=ojvybpUOVABD/T8gQD28sGV2jGI5unZxtdSfJ9Gi6Fg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UTcbvZTcVpxjYN9NVZxP21XbNfcFo2I0c91p61TK3a+RrunEhGZ1RUMu7wBr+KWw6nWpKcQroOigyqsGs1p0rtVoNk0tc1GZaOyaU7fXGCKjXBOjjWRpZzo6we20DP1hp8KRkPPbQASJid4RbGe+OK3hb5+rO6Q8CRp+Q6Z4hFQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=PL1vwJFB; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27224C4CEF7; Wed, 4 Feb 2026 14:43:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216227; bh=ojvybpUOVABD/T8gQD28sGV2jGI5unZxtdSfJ9Gi6Fg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PL1vwJFBVu4GDHNTSlZy5We19qE3t5DYbQYsIOzB+qzW9W3fzCIQlcNgjd4QaYJ0V P5jysMTHmlns7upeo+e09BvcTIuRP+iWOT3XKQmARdHMTnjS7KH9f6/fdaIR9bkEwg 5qNf8nzc7r3yECGrtv3KBUeTFP8MXLkGkl7QKtEk= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Filipe Manana , Qu Wenruo , David Sterba , Sasha Levin Subject: [PATCH 5.10 004/161] btrfs: send: check for inline extents in range_is_hole_in_parent() Date: Wed, 4 Feb 2026 15:37:47 +0100 Message-ID: <20260204143851.919366239@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260204143851.755002596@linuxfoundation.org> References: <20260204143851.755002596@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linuxfoundation.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Qu Wenruo [ Upstream commit 08b096c1372cd69627f4f559fb47c9fb67a52b39 ] Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items. Fixes: 82bfb2e7b645 ("Btrfs: incremental send, fix unnecessary hole writes for sparse files") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/send.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c index d86b4d13cae48..f144171ed6b7e 100644 --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -5892,6 +5892,8 @@ static int range_is_hole_in_parent(struct send_ctx *sctx, extent_end = btrfs_file_extent_end(path); if (extent_end <= start) goto next; + if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE) + return 0; if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) { search_start = extent_end; goto next; -- 2.51.0 From - Wed Feb 04 14:44:09 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 4EDxASlbg2nJ9RMAYBR5ng (envelope-from ) for ; Wed, 04 Feb 2026 14:43:53 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Wed, 04 Feb 2026 14:43:53 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vne6i-000000063N3-2KjJ for hi@josie.lol; Wed, 04 Feb 2026 14:43:53 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 6778F301177B for ; Wed, 4 Feb 2026 14:43:17 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0FFD3345CA5; Wed, 4 Feb 2026 14:43:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="NKj5oLDS" X-Original-To: stable@vger.kernel.org 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 E1C1F1EA84; Wed, 4 Feb 2026 14:43:15 +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=1770216196; cv=none; b=bnQ8hyCgWG72s2mEnGfb3flYcZ4EMnrY11sKxqj5djRZxXjaiKSLmG3MBm3eEGRJlTi2Ge0Ta4rwFO2UXpmkQhadufmfZLQOqKQEc4orbF3MuHkwAHRSSI/Giv37YO/s1JaUWq04nmDM54Nk6xCTN7RGHg1V7AXzgqYctBN70tE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770216196; c=relaxed/simple; bh=m2ktMt47fVMyof6SBXrwkoWZ+Cu0+uhwjIWAlRYNlo0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gGiYrN+byAzjJDU18WaYFBh9xQuWMXSnQpKjeWg5X3wfxync7TwkVTLUsh7SooeASJPFbUXEKLxve0f1EOPyQ8cpYBObBNXt4yFmJXBB+tz8eny8kMShHD6XvouqL+utbesZTcaCYJRv8hFLr0mCAHtQkGgZZA7VZnCEykRqimI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=NKj5oLDS; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18CBFC4CEF7; Wed, 4 Feb 2026 14:43:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1770216195; bh=m2ktMt47fVMyof6SBXrwkoWZ+Cu0+uhwjIWAlRYNlo0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NKj5oLDS1O/O+4mpHH2+oII2MVb+2XybMztzPGvHFAbQJAEyY8ZWQHZT0NeVfAHD6 f/opaU5Q5ZinFdvQctHxBpSOgWqYuFzFKDmSleBv8AZGZoO87kJxXVB816TFVpcKFf 8QOxH1t2PyF1AEO5xlroNkVf54pXSsEojV5GTwiQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Dan Carpenter , Amelie Delaunay , Vinod Koul , Sasha Levin Subject: [PATCH 5.10 016/161] phy: stm32-usphyc: Fix off by one in probe() her ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30F01365A1E; Mon, 23 Feb 2026 12:37:46 +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=1771850267; cv=none; b=JglqvgzFluiABUkcOCf+jTJI6qiEMEjeuCztjQeA0SNw5g2pYhZEsFls5avgE6Odyrptf97UEvFsa4Jg2gKaB1JwK5hthuVo8QhSHF+X1OsynAB5Pw7AcmJAvT0IjC2edYdwZXgGSfIUvV9NE9EjV2Sd4+0KvONMNOB+LDVcD7Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771850267; c=relaxed/simple; bh=8FmYs+QrdSDFMbKC7QBfwAXPK2pJJB0FmB/uWUvKPnc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=eIgLWyAuti+9De6574pUBDdlXZ31i+0LapzS/akSIQ+tPNohLqlKrVPxvL+796p0OtOamf/8Fgl/fiXdxLJ7X1FbwR/PlCxwlGwaJ+rcssEPQyDV97TwpsPGt56kmc1h4wKFXFpI2qVjX2CG69F9rwjv8MWXmuECrLS/7vp3wdc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WOJ84LIB; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0998CC2BC9E; Mon, 23 Feb 2026 12:37:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771850266; bh=8FmYs+QrdSDFMbKC7QBfwAXPK2pJJB0FmB/uWUvKPnc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WOJ84LIBNwGlaD8YoCJIe2RS1r4Xg7VHNPOF2YM9Ki84Q25tEIHa0mlvFcwq7cUXN PptNKboPgj9OCh2r77JO57Ra38b1lSoiofOoEo0UHTPPFYO33w5w5+yw6g6G6N02EB oCP0YrSgntGEttNrX7YB58tnX23aXDRFnNcwnZSOgCnSVQ9zU2KRn9ZvBJxokX/y4Y b9LuAfNjsrgcRNPerc3uvCPK8zQ0uOgPq1ory/kDZN+YhleuJllZxWFGgH4vZJ0voF N+kZ5dga6fQvNqWn75Fnl3NEFSWCRrX1zPoysPNXOSF0aFElnb0ZX337FsIBD7aldf YL8W08SHB2oNg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Takashi Iwai , Sasha Levin , perex@perex.cz, tiwai@suse.com, linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.19-5.15] ALSA: usb-audio: Add sanity check for OOB writes at silencing Date: Mon, 23 Feb 2026 07:37:10 -0500 Message-ID: <20260223123738.1532940-5-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org> References: <20260223123738.1532940-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.19.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://docs.mxroute.com/docs/expert-spam-filtering.html --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: msgid.link] 0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to dbl.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [URIs: msgid.link] 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.234.253.10 listed in zen.spamhaus.org] 0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [URIs: msgid.link] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Takashi Iwai [ Upstream commit fba2105a157fffcf19825e4eea498346738c9948 ] At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076 Link: https://patch.msgid.link/20260216141209.1849200-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ## Analysis ### What the commit fixes This commit adds bounds checking to `prepare_silent_urb()` in the USB audio driver to prevent **out-of-bounds memory writes** that cause a **kernel panic/oops**. The bug occurs during implicit feedback mode when silencing playback URB packets before actual playback begins. When the capture stream has different (larger) packet sizes than the playback stream (e.g., due to USB core max packet size limitations), the code writes beyond the allocated transfer buffer, corrupting memory and crashing the kernel. ### Bug severity This is a **kernel crash/oops** triggered by real hardware. The bugzilla report (bug #221076) documents: - Hard system lockups / kernel panics on multiple platforms (Intel, AMD, Raspberry Pi 5) - Reproducible with specific USB audio devices at high sample rates (352.8kHz/384kHz, 6-channel) - The crash trace shows `memset_orig` called from `prepare_outbound_urb` → page fault on not-present page - The regression was traced back to kernel 5.8.0, meaning it has affected users for years ### Code change analysis The fix is small (22 insertions, 17 deletions, single file) and surgical: 1. **Return type change**: `prepare_silent_urb()` changes from `void` to `int` to report errors 2. **Negative return check**: Checks if `snd_usb_endpoint_next_packet_size()` returns a negative error code before using the value 3. **Buffer bounds check**: `if (offs + length + extra > ctx->buffer_size) break;` — stops copying if data would overflow the buffer 4. **Error propagation**: Returns `-EPIPE` if nothing was written, `0` on success 5. **Caller updated**: `prepare_outbound_urb()` now returns the error from `prepare_silent_urb()` instead of ignoring it ### Stable kernel criteria assessment - **Obviously correct**: Yes — adds bounds checking before memory writes, a straightforward safety measure - **Fixes a real bug**: Yes — kernel oops/panic with real hardware, documented in bugzilla with crash traces - **Small and contained**: Yes — 22 insertions/17 deletions in a single file, no API changes - **No new features**: Correct — purely defensive checks - **Risk**: Very low — the check only prevents writing beyond the buffer; normal operation is unchanged ### Dependencies The commit modifies only `prepare_silent_urb()` and its caller in `prepare_outbound_urb()`. The `ctx->buffer_size` field has been present since the URB context structure was established. No prerequisite commits appear needed. ### Verification - Confirmed via the bugzilla report (bug #221076) that this is a real user-reported crash with kernel oops trace showing `memset_orig` page fault in `prepare_outbound_urb` call path - The bug has been present since kernel 5.8.0 per user bisection, meaning all stable trees are affected - Explored `snd_usb_endpoint_next_packet_size()` — confirmed it can return negative (`-EAGAIN`), which was not checked before this fix - Confirmed `ctx->buffer_size` is set in `data_ep_set_params()` as `maxsize * packets`, and the transfer buffer is allocated to that size — so the bounds check is valid - The commit is authored by Takashi Iwai (ALSA maintainer), providing high confidence in correctness - The commit message explicitly states it covers a kernel Oops — a clear stable-worthy fix - Commit touches only `sound/usb/endpoint.c` (1 file, small diff) This is a textbook stable backport candidate: a small, surgical fix for a kernel crash affecting real users, authored by the subsystem maintainer, with low regression risk. **YES** sound/usb/endpoint.c | 39 ++++++++++++++++++++++----------------- 1 file changed, 22 insertions(+), 17 deletions(-) diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c index 27ade2aa16f5a..1eaf52d1ae9c7 100644 --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -275,8 +275,8 @@ static inline bool has_tx_length_quirk(struct snd_usb_audio *chip) return chip->quirk_flags & QUIRK_FLAG_TX_LENGTH; } -static void prepare_silent_urb(struct snd_usb_endpoint *ep, - struct snd_urb_ctx *ctx) +static int prepare_silent_urb(struct snd_usb_endpoint *ep, + struct snd_urb_ctx *ctx) { struct urb *urb = ctx->urb; unsigned int offs = 0; @@ -289,28 +289,34 @@ static void prepare_silent_urb(struct snd_usb_endpoint *ep, extra = sizeof(packet_length); for (i = 0; i < ctx->packets; ++i) { - unsigned int offset; - unsigned int length; - int counts; - - counts = snd_usb_endpoint_next_packet_size(ep, ctx, i, 0); - length = counts * ep->stride; /* number of silent bytes */ - offset = offs * ep->stride + extra * i; - urb->iso_frame_desc[i].offset = offset; + int length; + + length = snd_usb_endpoint_next_packet_size(ep, ctx, i, 0); + if (length < 0) + return length; + length *= ep->stride; /* number of silent bytes */ + if (offs + length + extra > ctx->buffer_size) + break; + urb->iso_frame_desc[i].offset = offs; urb->iso_frame_desc[i].length = length + extra; if (extra) { packet_length = cpu_to_le32(length); - memcpy(urb->transfer_buffer + offset, + memcpy(urb->transfer_buffer + offs, &packet_length, sizeof(packet_length)); + offs += extra; } - memset(urb->transfer_buffer + offset + extra, + memset(urb->transfer_buffer + offs, ep->silence_value, length); - offs += counts; + offs += length; } - urb->number_of_packets = ctx->packets; - urb->transfer_buffer_length = offs * ep->stride + ctx->packets * extra; + if (!offs) + return -EPIPE; + + urb->number_of_packets = i; + urb->transfer_buffer_length = offs; ctx->queued = 0; + return 0; } /* @@ -332,8 +338,7 @@ static int prepare_outbound_urb(struct snd_usb_endpoint *ep, if (data_subs && ep->prepare_data_urb) return ep->prepare_data_urb(data_subs, urb, in_stream_lock); /* no data provider, so send silence */ - prepare_silent_urb(ep, ctx); - break; + return prepare_silent_urb(ep, ctx); case SND_USB_ENDPOINT_TYPE_SYNC: if (snd_usb_get_speed(ep->chip->dev) >= USB_SPEED_HIGH) { -- 2.51.0 From - Mon Feb 23 12:40:15 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id sMaxHatKnGlkoBUAYBR5ng (envelope-from ) for ; Mon, 23 Feb 2026 12:40:11 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 23 Feb 2026 12:40:11 +0000 Received: from sto.lore.kernel.org ([172.232.135.74]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vuVEQ-00000006wwG-2eLb for hi@josie.lol; Mon, 23 Feb 2026 12:40:11 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id E5490304DEA4 for ; Mon, 23 Feb 2026 12:38:41 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 88BF3366DDE; Mon, 23 Feb 2026 12:38:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Dxq2xMUE" X-Original-To: stable@vger.kernel.org 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 6242036654A; Mon, 23 Feb 2026 12:38:06 +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=1771850286; cv=none; b=rals67YXxfisVNxBtyBzPlpAZ2nk1VlePf/WN/E7OoF9+5gHZF3lYusQ1XNgr7CLMt00UXYpEXkxylk0dyFpkwdZ231hS8BXAVIZJ241WHQDzmK843aU7cV6G9UPbsG6ufQC1Dq6TXL4QChGgOX8ksCN7ERn0ajkWqedqIF8Y+I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771850286; c=relaxed/simple; bh=EfL1zGl01oo4GS5HNkMgV5OVgLXxYcXRoLCBrmlcPQQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=libWlfT2u/2mvZCf+SzuDh6c+siOYJuA1MtQlJ+eI9e5DD3PGyLWQTvRPIv8zjickHWWrA+bv98doA0GStO8AmkMyfxQS0Aqb7iFrwphuEQl3IX3HuoE3ErhoHJJ/tvL4Yslh+m3h0NunL/w/2g+G+8CkQ/NqQNMOBkgnG4oZE0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Dxq2xMUE; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DAABC2BC86; Mon, 23 Feb 2026 12:38:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771850286; bh=EfL1zGl01oo4GS5HNkMgV5OVgLXxYcXRoLCBrmlcPQQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Dxq2xMUEYjAP/TINOt3M+vG1ghNlYHGqZr060RjoAFlI/Fusv6dCUJwN5XKwBepyI PfDeeFPQUzm0f7aQwnDn2iXaufuEXQgDpp6bvgTUKItygIJ6XhcIYU42neJBLC/1fX HE0iZhSUKiw4QpMHVOUdDImqGuVXURm5eb/ySKYKyZbdo88GPBNX5sj3q78eHxM+qZ NqSU8rSE0pBPcyburmBqux65U3EfPLxDCfjYydDX5nw+xsrXY3kHXSHFK4Pv1tYg4G qnRZCSFTmlgWMpfrRV18oinWygTgAexv52YGJ8e3WsKez/yjxz23uCJdYXAOIG4/ZL G16nAeB1tC/5A== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Qu Wenruo , Christoph Hellwig , David Sterba , Sasha Levin , clm@fb.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.19] btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure() Date: Mon, 23 Feb 2026 07:37:23 -0500 Message-ID: <20260223123738.1532940-18-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org> References: <20260223123738.1532940-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.19.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://docs.mxroute.com/docs/expert-spam-filtering.html --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: qemu.org] 0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to dbl.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [URIs: qemu.org] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.232.135.74 listed in list.dnswl.org] 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.232.135.74 listed in zen.spamhaus.org] 0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [URIs: qemu.org] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Qu Wenruo [ Upstream commit 8ceaad6cd6e7fa5f73b0b2796a2e85d75d37e9f3 ] [BUG] There is a bug report that when btrfs hits ENOSPC error in a critical path, btrfs flips RO (this part is expected, although the ENOSPC bug still needs to be addressed). The problem is after the RO flip, if there is a read repair pending, we can hit the ASSERT() inside btrfs_repair_io_failure() like the following: BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -28) WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844 Modules linked in: kvm_intel kvm irqbypass [...] ---[ end trace 0000000000000000 ]--- BTRFS info (device vdc state EA): 2 enospc errors during balance BTRFS info (device vdc state EA): balance: ended with status: -30 BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6 BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0 [...] assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938 ------------[ cut here ]------------ assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938 kernel BUG at fs/btrfs/bio.c:938! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full) Tainted: [W]=WARN, [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Workqueue: btrfs-endio simple_end_io_work RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120 RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246 RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988 R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310 R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000 FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ------------[ cut here ]------------ [CAUSE] The cause of -ENOSPC error during the test case btrfs/124 is still unknown, although it's known that we still have cases where metadata can be over-committed but can not be fulfilled correctly, thus if we hit such ENOSPC error inside a critical path, we have no choice but abort the current transaction. This will mark the fs read-only. The problem is inside the btrfs_repair_io_failure() path that we require the fs not to be mount read-only. This is normally fine, but if we are doing a read-repair meanwhile the fs flips RO due to a critical error, we can enter btrfs_repair_io_failure() with super block set to read-only, thus triggering the above crash. [FIX] Just replace the ASSERT() with a proper return if the fs is already read-only. Reported-by: Christoph Hellwig Link: https://lore.kernel.org/linux-btrfs/20260126045555.GB31641@lst.de/ Tested-by: Christoph Hellwig Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: The same ASSERT exists in v6.1 too (in extent_io.c instead of bio.c). The bug is present across all stable trees. ## Analysis ### What problem does this commit solve? This commit fixes a **kernel BUG/crash** (not just a warning) that occurs when: 1. The btrfs filesystem encounters a critical error (e.g., ENOSPC in a critical path) 2. The filesystem flips to read-only mode (transaction abort) 3. Meanwhile, a concurrent read-repair operation calls `btrfs_repair_io_failure()` 4. The ASSERT checks `!(fs_info->sb->s_flags & SB_RDONLY)` and fails 5. Since btrfs's `ASSERT()` macro calls `BUG()`, this causes a kernel oops/crash The crash is confirmed by the stack trace in the commit message showing `kernel BUG at fs/btrfs/bio.c:938!`. ### Does it meet stable kernel rules? 1. **Obviously correct and tested**: Yes. The fix replaces an ASSERT (which calls BUG()) with a graceful `return 0` when the filesystem is read-only. It has `Tested-by: Christoph Hellwig` and `Reviewed-by: David Sterba` (btrfs maintainer). 2. **Fixes a real bug**: Yes. A kernel BUG/crash is triggered. The bug report is linked and comes from Christoph Hellwig, a prominent kernel developer. 3. **Fixes an important issue**: Yes. This is a kernel crash (oops via BUG()). If a filesystem encounters a critical error and goes RO, a concurrent read-repair shouldn't crash the entire system. 4. **Small and contained**: Yes. The change removes one line (`ASSERT(...)`) and adds a 4-line `if (unlikely(sb_rdonly(...))) return 0;` check. Total: ~6 lines changed in one file. 5. **Does NOT introduce new features**: Correct. It only changes error handling. ### Risk vs Benefit - **Risk**: Extremely low. Replacing a crash (BUG()) with a graceful return (0 = success, skip repair) is safe. If the filesystem is already RO, skipping the repair write is correct behavior — you can't write to a RO filesystem anyway. - **Benefit**: High. Prevents kernel crash in a race condition that real users hit (reported by Christoph Hellwig during btrfs/124 test). ### Backport considerations The function signature has changed significantly across versions: - **v6.6**: Uses `struct page *page` parameter — different signature but the ASSERT is identical - **v6.12**: Uses `struct folio *folio` parameter — different signature but the ASSERT is identical - **Current**: Uses `const phys_addr_t paddrs[]` parameter However, the **fix itself** (remove ASSERT, add `if (sb_rdonly(...)) return 0`) is signature-independent and applies to all versions. A minor adaptation to the surrounding context will be needed for each stable tree, but the core fix is trivial. ### Verification - **Verified**: The ASSERT macro in btrfs calls `BUG()` (confirmed in `fs/btrfs/messages.h` lines 139-152) - **Verified**: The buggy ASSERT exists in v6.12 and v6.6 stable trees (checked via `git show v6.12:fs/btrfs/bio.c` and `git show v6.6:fs/btrfs/bio.c`) - **Verified**: The buggy ASSERT also exists in v6.1 (in `fs/btrfs/extent_io.c` rather than `bio.c`, function named `repair_io_failure`) - **Verified**: The function has two callers: `btrfs_end_repair_bio()` (bio.c) and `btrfs_repair_eb_io_failure()` (disk-io.c), both in I/O completion paths that can race with filesystem RO transitions - **Verified**: The commit has `Tested-by: Christoph Hellwig`, `Reviewed-by: David Sterba`, and `Reported-by: Christoph Hellwig` with a link to the bug report - **Verified**: The fix is a clean 6-line change — remove ASSERT, add early return with comment - **Verified**: The function signature differs across stable trees (page vs folio vs phys_addr_t), but the fix concept (remove ASSERT, add sb_rdonly check) is identical and straightforward to adapt This is a textbook stable backport candidate: a small, well-reviewed fix for a kernel crash in a race condition, reported by a trusted developer, in a widely-used filesystem. The fix is obviously correct — when the fs is RO, there's nothing to repair and crashing is worse than skipping. **YES** fs/btrfs/bio.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/bio.c b/fs/btrfs/bio.c index fa1d321a2fb83..45bd3c3b6d793 100644 --- a/fs/btrfs/bio.c +++ b/fs/btrfs/bio.c @@ -935,7 +935,6 @@ int btrfs_repair_io_failure(struct btrfs_fs_info *fs_info, u64 ino, u64 fileoff, struct bio *bio = NULL; int ret = 0; - ASSERT(!(fs_info->sb->s_flags & SB_RDONLY)); BUG_ON(!mirror_num); /* Basic alignment checks. */ @@ -947,6 +946,13 @@ int btrfs_repair_io_failure(struct btrfs_fs_info *fs_info, u64 ino, u64 fileoff, ASSERT(step <= length); ASSERT(is_power_of_2(step)); + /* + * The fs either mounted RO or hit critical errors, no need + * to continue repairing. + */ + if (unlikely(sb_rdonly(fs_info->sb))) + return 0; + if (btrfs_repair_one_zone(fs_info, logical)) return 0; -- 2.51.0 From - Mon Feb 23 12:40:23 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 2NRpNLJKnGltFxkAYBR5ng (envelope-from ) for ; Mon, 23 Feb 2026 12:40:18 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 23 Feb 2026 12:40:19 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vuVEY-00000006xCu-20Bn for hi@josie.lol; Mon, 23 Feb 2026 12:40:18 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id A60783073858 for ; Mon, 23 Feb 2026 12:38:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EE843366838; Mon, 23 Feb 2026 12:38:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BSXP/k2s" X-Original-To: stable@vger.kernel.org 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 C8C51366835; Mon, 23 Feb 2026 12:38:00 +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=1771850280; cv=none; b=BuIqwXbQbEiyEAZbyBt4JvW+pnDOdANLKjV5obyXHPHy3145hb8S/+VgaFyCrd7IdvruQAA7AcuISwefpf1mjiZmmpO6w+S+L5IU+uak1s9MFvK8ZYq4dLgBoFz1FEHhHxwJHcwARGqIh9rVRCICiZnjBLWXGDx9+j5wMLo6sss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771850280; c=relaxed/simple; bh=iHZa8nYe42r2IjJzinLnQVMLFp3VrGSWpay58wvZsmw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mY20Rys+LgYJHALLNvW4iC9SP2obtC/P6+z/r0Pvm2Y3xku6XayVbLrws3QKv/KUpMBeMiUSKfi10dI07zFrPZGeQFEK0zJFhHjufLQagQCyZVKMwZk0c/Pxf14YGfmy+mXQFvFLrJHFRS8jFISAgNkB+4YTRdmxMtyf1yvGyyg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BSXP/k2s; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2758BC4AF0C; Mon, 23 Feb 2026 12:37:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771850280; bh=iHZa8nYe42r2IjJzinLnQVMLFp3VrGSWpay58wvZsmw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BSXP/k2sWKkXL0NuDeNI7dhVQSMrgkG2/+kBnm33XygN2m5TrOGFCFkXc+TBLrfpW W8BndV/+jMANV0wfaBuJ9zCjWTuFT66y7z33tOPzC57gVhqCQzBA9CaCmc7o9MG9NB SIaWLAbdot1KfZrnjT/fQYf50QX2+wXDdQZfarF22z4gf24Gkh/V1rdqbeX/L4aJ6a cCQHDthNLeq5HOGAaBVuqpU/76DlcD8/oCT6rVWjw9KrV7wQaeNexerchKCTY/pz3i cWd55/rdVomjGn54VgeqXcSbGlRHwGRbsDuIs6MXoCB7WDrXUPIGJZU904UlwrCdS7 +H+kBlOjQaWkQ== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Victor Zhao , Alex Deucher , Sasha Levin , christian.koenig@amd.com, airlied@gmail.com, simona@ffwll.ch, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.19-6.18] drm/amdgpu: avoid sdma ring reset in sriov Date: Mon, 23 Feb 2026 07:37:19 -0500 Message-ID: <20260223123738.1532940-14-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org> References: <20260223123738.1532940-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.19.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://docs.mxroute.com/docs/expert-spam-filtering.html --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.105.105.114 listed in zen.spamhaus.org] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Victor Zhao [ Upstream commit 5cc7bbd9f1b74d9fe2f7ac08d6ba0477e8d2d65f ] sdma ring reset is not supported in SRIOV. kfd driver does not check reset mask, and could queue sdma ring reset during unmap_queues_cpsch. Avoid the ring reset for sriov. Signed-off-by: Victor Zhao Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: The background task completed but my analysis is already finished. The result would show the same finding I already verified — that `amdgpu_sdma_reset_engine` was introduced in the v6.15 cycle. My final answer remains **YES** — this is a small, correct bug fix for SR-IOV environments that prevents SDMA scheduler work queues from being left in a stopped state. drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c index 8b8a04138711c..321310ba2c08e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c @@ -558,6 +558,9 @@ int amdgpu_sdma_reset_engine(struct amdgpu_device *adev, uint32_t instance_id, struct amdgpu_ring *gfx_ring = &sdma_instance->ring; struct amdgpu_ring *page_ring = &sdma_instance->page; + if (amdgpu_sriov_vf(adev)) + return -EOPNOTSUPP; + mutex_lock(&sdma_instance->engine_reset_mutex); if (!caller_handles_kernel_queues) { -- 2.51.0 From - Mon Feb 23 12:40:27 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id SNQyKbVKnGltFxkAYBR5ng (envelope-from ) for ; Mon, 23 Feb 2026 12:40:21 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 23 Feb 2026 12:40:21 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vuVEa-00000006xEo-4C2m for hi@josie.lol; Mon, 23 Feb 2026 12:40:21 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 3D4DD30B54C7 for ; Mon, 23 Feb 2026 12:37:53 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0036F366554; Mon, 23 Feb 2026 12:37:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PGqkAMqO" X-Original-To: stable@vger.kernel.org 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 CE6EF365A02; Mon, 23 Feb 2026 12:37:48 +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=1771850268; cv=none; b=p7H4fChwE8y22hzDjiVtHSOFGxdjs/ORLKK44KqFP42hDSuZP+lYWaXZjLuDIAcl1/au+hQfl/oISA8yoNcm92ObGozOXNogtzhpw01os6+/G3Zx4QKboJ9KOAk1MnsIysMzNu+5Vl3SAEY+RkMvfcpnvYCnF4N1jKzJRMk+pKc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771850268; c=relaxed/simple; bh=ieO3IDaCxW655UojJOwVdh3Cqjs3Mef/DOUYYLZgQfY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Mj5P7aUaWneaFMd5AVJCtk0QuVBoEhgGynK0EaYA5ms2RjAfvMEVDY0DzDTNPV//W4Sv26h2LNLRRqvQdZYcZPb27WevDMuKeJ5K/kw/GS/BkltuvXpu2KI0BgEj7rwt2GRhFLTeR2g/YqfJhqZbMYDbdcQNHknAjLXhf2W+QAI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PGqkAMqO; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C854C116D0; Mon, 23 Feb 2026 12:37:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771850268; bh=ieO3IDaCxW655UojJOwVdh3Cqjs3Mef/DOUYYLZgQfY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PGqkAMqOuiB6v5WERJJ25jDW7mmx+7GSfSp3/2YybdIlEzVUW5V6AIRqtwMRxWcqO YlJLSN+bO8LvxKT+NQ8RP4NXBUyr/NpwFjg0zqOWUs/UdTxW2B7a/7f/0UgYgdWIh8 XyUNEgcHe1AYzazA5aBIxIFzYem20IITCKLrQzXK7OIEoWorLp7rpJ5xoPfBbkY0p9 jSiLKVtsk/tKbLfR/xf4BoiHg1Yufh7vymI59xPV9FEz5N47hnn//JHAJFJXEFZgdo 84MQxiaiIjEkDTZ12dkfzCf65iCAMLKx/bpQqAfR/1fYz+fn/Y2f4jqNr28UyHAqC+ MRSYZu76UkpGw== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Tom Chung , Nicholas Kazlauskas , Wayne Lin , Daniel Wheeler , Alex Deucher , Sasha Levin , harry.wentland@amd.com, sunpeng.li@amd.com, christian.koenig@amd.com, airlied@gmail.com, simona@ffwll.ch, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.19-6.12] drm/amd/display: Fix system resume lag issue Date: Mon, 23 Feb 2026 07:37:11 -0500 Message-ID: <20260223123738.1532940-6-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org> References: <20260223123738.1532940-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.19.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://docs.mxroute.com/docs/expert-spam-filtering.html --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.234.253.10 listed in zen.spamhaus.org] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Tom Chung [ Upstream commit 64c94cd9be2e188ed07efeafa6a109bce638c967 ] [Why] System will try to apply idle power optimizations setting during system resume. But system power state is still in D3 state, and it will cause the idle power optimizations command not actually to be sent to DMUB and cause some platforms to go into IPS. [How] Set power state to D0 first before calling the dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false) Reviewed-by: Nicholas Kazlauskas Signed-off-by: Tom Chung Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Good. Now I have all the information needed for my analysis. --- ## Analysis ### 1. Commit Message Analysis The commit clearly describes a **system resume lag issue** on AMD display platforms with IPS (Idle Power States) support. The commit is structured with `[Why]` and `[How]` sections explaining the root cause and fix: - **Root Cause**: During system resume, `dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false)` is called to disable idle power optimizations, but at that point the DMUB power state is still D3 (suspended). The DMUB firmware won't execute commands when in D3 state, so the idle power optimization disable command silently fails, causing some platforms to incorrectly enter IPS during resume. - **Fix**: Set DMUB power state to D0 *before* calling the idle power optimizations command. ### 2. Code Change Analysis The change is **+10 lines** in a single file. It adds: 1. `dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, DC_ACPI_CM_POWER_STATE_D0)` — sets DMUB to active power state before sending commands 2. Mutex locking around the operation (`dm->dc_lock`) for the non-reset resume path 3. The `amdgpu_in_reset()` check for mutex matches the existing pattern in the reset path (which already holds the lock) The fix is clearly correct: looking at line 3559 of the current code, the normal (non-IPS-early) resume path already calls `dc_dmub_srv_set_power_state(D0)` before other operations. The early IPS block was simply missing this prerequisite call. ### 3. Bug Severity This is a **real user-visible bug** — system resume lag/hang on AMD platforms with IPS support (DCN35+ hardware, e.g., AMD Ryzen mobile APUs). This affects: - Laptop users doing S3/S4 suspend/resume - The fix prevents displays from being stuck/lagging after system resume - Tested-by Daniel Wheeler (AMD) confirms hardware validation ### 4. Scope and Risk - **Very small**: Only 10 lines added to a single file - **Surgically targeted**: Only affects the early IPS power optimization block in `dm_resume()` - **Pattern consistent**: The fix follows the exact same pattern used in the GPU-reset resume path (line 3500) and the normal resume path (line 3559), both of which already call `dc_dmub_srv_set_power_state(D0)` first - **Well-reviewed**: Reviewed by Nicholas Kazlauskas (AMD display expert), Tested by Daniel Wheeler (AMD QA), Signed-off by Wayne Lin and Alex Deucher (AMD display maintainer) - **Low regression risk**: Adding D0 power state before a command is purely correctional — the command already expected D0 state ### 5. Dependencies - `dc_dmub_srv_set_power_state()` was introduced in commit `0f657938e4345` (v6.8) - The buggy `dc_dmub_srv_apply_idle_power_optimizations()` call in `dm_resume` was added around v6.9 - The `dm->dc_lock` mutex has existed since the display manager was created - **No missing dependencies** — all required functions exist in v6.9+ stable trees ### 6. Stable Tree Applicability The fix applies to kernels **v6.9+** where the IPS check in `dm_resume` exists. The code is self-contained and should apply cleanly to recent stable trees (6.12.y, 6.6.y may need checking for ips_support code). ### Verification - Verified the exact diff via `git diff 64c94cd9be2e1^..64c94cd9be2e1`: confirms +10 line change, single file - Verified `dc_dmub_srv_set_power_state()` implementation at `dc_dmub_srv.c:1572-1585`: simple power state setter, calls `dmub_srv_set_power_state()` - Verified the function was introduced in commit `0f657938e4345` (first in v6.8-rc1) via `git tag --contains` - Verified the buggy IPS check (`ips_support` + `apply_idle_power_optimizations` in `dm_resume`) was added around v6.9 via `git tag --contains 60818ed76577c` - Verified `dm->dc_lock` mutex exists at `amdgpu_dm.h:446` - Verified the normal resume path already calls `dc_dmub_srv_set_power_state(D0)` at line 3559, confirming the fix follows the established pattern - Verified the GPU-reset resume path also calls `dc_dmub_srv_set_power_state(D0)` at line 3500, same pattern - Could NOT verify via lore.kernel.org whether there are known regressions from this fix (unverified, but low concern given AMD testing) ### Conclusion This is a clear, well-tested bug fix for a real user-visible issue (system resume lag/hang on AMD IPS-capable platforms). The fix is small (+10 lines), surgical, follows established patterns in the same function, has been reviewed and tested by AMD engineers, and has no feature additions. It meets all stable kernel criteria. **YES** drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index a72394b05ab02..e004fc3893edf 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3468,7 +3468,17 @@ static int dm_resume(struct amdgpu_ip_block *ip_block) struct dc_commit_streams_params commit_params = {}; if (dm->dc->caps.ips_support) { + if (!amdgpu_in_reset(adev)) + mutex_lock(&dm->dc_lock); + + /* Need to set POWER_STATE_D0 first or it will not execute + * idle_power_optimizations command to DMUB. + */ + dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, DC_ACPI_CM_POWER_STATE_D0); dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false); + + if (!amdgpu_in_reset(adev)) + mutex_unlock(&dm->dc_lock); } if (amdgpu_in_reset(adev)) { -- 2.51.0 From - Mon Feb 23 12:40:39 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 0ECyAMNKnGlN3BcAYBR5ng (envelope-from ) for ; Mon, 23 Feb 2026 12:40:35 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 23 Feb 2026 12:40:35 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vuVEo-00000006xda-0NEk for hi@josie.lol; Mon, 23 Feb 2026 12:40:34 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 6995D307D81E for ; Mon, 23 Feb 2026 12:38:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D3C6336683F; Mon, 23 Feb 2026 12:38:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VOJkvleo" X-Original-To: stable@vger.kernel.org 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 AD9EB36606F; Mon, 23 Feb 2026 12:38:01 +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=1771850281; cv=none; b=DFNyk1g5O9YYq7x/RtnV54NlTpFbveAwdWy6pfpGCQakeyK6fdhSnAXy1AUSZKi6et7k7mhpCoI2J76SJMHz/A3irlQiZIR4fuHPdDnqUxlyGa6AzzSTryh3I8jsEJ5PkNFFKrFO2Z6QF+HA/iPWFIXcckvMsRCHWYmZqKynxrU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771850281; c=relaxed/simple; bh=joVrSiLBOUSMSp4SN28ckyepXrgflCGpqwb34ECohbQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ML2SNyQs6QbQSfZeq9T0FZS0rKb6Y1S3lRU2UhrLx2VOI0XnQb7WMeykcP0EX9gnexJGDsuyZewpqePCWRyC23cfhrH+yIKHGX+aS/RhjooTTB7TdkJ51Dz/nOLATK0OBjDIGLamjO9QzuRdmNsKuZG56fs2DdikzSRwHg5IjxU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VOJkvleo; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D01FC2BCB0; Mon, 23 Feb 2026 12:38:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771850281; bh=joVrSiLBOUSMSp4SN28ckyepXrgflCGpqwb34ECohbQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VOJkvleoRyxxJBgKnCSjrLlKEqO/Bae44WRozp1sNzRfZW+sdkxINKKjZLxwzUGKW DfQwFx1eSvT+tFLn5ridssspwPHqHJEAnH1Y7cGywaMJQH4rdxxX+7tnRXzRsTLWSm hPERjm97vdZkDt9aT2qTyhnc9C/Ng3V4m+ay0mYa/PJtB2sOj9E/xoJWQ9pbJdfS0X 8QWiNuZ+Q30wsBy2sei12Jv5OL9MQu3amUXh3DT3s+DzoYO66eLMv2pjR48ercLbNQ FsF6+fB9T+ifIEFyhofE8cafDUWI9oK8Upa7nXGnK7ePT/T1PHT4kK8J32HJLqpqyb mcZIYaTUKrK3Q== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Fabian Godehardt , Mark Brown , Sasha Levin , linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.19-6.12] spi: spidev: fix lock inversion between spi_lock and buf_lock Date: Mon, 23 Feb 2026 07:37:20 -0500 Message-ID: <20260223123738.1532940-15-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org> References: <20260223123738.1532940-1-sashal@kernel.org> Precedence: bulk X-Maili