elaxed/simple; d=linuxfoundation.org; s=korg; t=1761076705; bh=JU5G1jmo3mzCK3zgzta77f+xALcwk79VFl4t6bjIh4k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ktsIrfVQdoi3tui6VWRe8aquHIVqV9b4hbam7coycmxn8m/9ewkyxfSAVbYIaNiNO mCqtTp7RZwJZoSKp+tNgzzS3d0t4PvFS/623SIRfYHLzSa+oDKnQNgOHZXFA27bjPm RRWGfvIqMCRVIdkW2vvVSvPBiD7rd76zzsUUJYHU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Max Chernoff , Filipe Manana , Boris Burkov , David Sterba Subject: [PATCH 6.12 013/136] btrfs: fix incorrect readahead expansion length Date: Tue, 21 Oct 2025 21:50:01 +0200 Message-ID: <20251021195036.286463816@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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. [147.75.80.249 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Boris Burkov commit 8ab2fa69691b2913a67f3c54fbb991247b3755be upstream. The intent of btrfs_readahead_expand() was to expand to the length of the current compressed extent being read. However, "ram_bytes" is *not* that, in the case where a single physical compressed extent is used for multiple file extents. Consider this case with a large compressed extent C and then later two non-compressed extents N1 and N2 written over C, leaving C1 and C2 pointing to offset/len pairs of C: [ C ] [ N1 ][ C1 ][ N2 ][ C2 ] In such a case, ram_bytes for both C1 and C2 is the full uncompressed length of C. So starting readahead in C1 will expand the readahead past the end of C1, past N2, and into C2. This will then expand readahead again, to C2_start + ram_bytes, way past EOF. First of all, this is totally undesirable, we don't want to read the whole file in arbitrary chunks of the large underlying extent if it happens to exist. Secondly, it results in zeroing the range past the end of C2 up to ram_bytes. This is particularly unpleasant with fs-verity as it can zero and set uptodate pages in the verity virtual space past EOF. This incorrect readahead behavior can lead to verity verification errors, if we iterate in a way that happens to do the wrong readahead. Fix this by using em->len for readahead expansion, not em->ram_bytes, resulting in the expected behavior of stopping readahead at the extent boundary. Reported-by: Max Chernoff Link: https://bugzilla.redhat.com/show_bug.cgi?id=2399898 Fixes: 9e9ff875e417 ("btrfs: use readahead_expand() on compressed extents") CC: stable@vger.kernel.org # 6.17 Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -962,7 +962,7 @@ static void btrfs_readahead_expand(struc { const u64 ra_pos = readahead_pos(ractl); const u64 ra_end = ra_pos + readahead_length(ractl); - const u64 em_end = em->start + em->ram_bytes; + const u64 em_end = em->start + em->len; /* No expansion for holes and inline extents. */ if (em->disk_bytenr > EXTENT_MAP_LAST_BYTE) From - Tue Oct 21 19:58:34 2025 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 yOpRHufl92jAsg0AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:31 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:31 +0000 Received: from am.mirrors.kernel.org ([147.75.80.249]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIV5-00000004NSd-0nV2 for hi@josie.lol; Tue, 21 Oct 2025 19:58:31 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 5DCBA19A4643 for ; Tue, 21 Oct 2025 19:58:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D4E0D274652; Tue, 21 Oct 2025 19:58:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="e6u1Mmqo" 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 AD67B350A2A; Tue, 21 Oct 2025 19:58: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=1761076708; cv=none; b=dvGvC2b/EjE/BWZM9EFGgQE5rGSDLrfkmGpL+ueATcwCZn+vLJFjIFSgaUwwniyfHJ2uX4UQIygjP5OaIpgOeEqMIGCGvKZGfHhaw4B4PXj723vKqcZplPgM684LzyldarF6iPy5SVkrhjp6w0OFn/G2Zk5+R+ahxizciPV9Rno= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076708; c=relaxed/simple; bh=amUU4/LKaAvwhokRxAg0ANQkLryV1tWVL0IzREJj5Z4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=iT9LYpN7joY+h+JZ+KyfpMPurLYWe4W1JGXMbhM9PvTfHm+fs18outXNpSi0ZzgShwKCQepdinc4R1VpEZVv+NT3K8BJhvWIWVkhJzJaNPg65+kMj86YZjjplyhhsvEIu4kKJaBG9fYPZgex/ubtH1TWiL00qAcDtOV7rRoOuTU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=e6u1Mmqo; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 105FBC4CEF1; Tue, 21 Oct 2025 19:58:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076708; bh=amUU4/LKaAvwhokRxAg0ANQkLryV1tWVL0IzREJj5Z4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=e6u1Mmqozi1SP3FBUmBIhMtwM80cgk0cnXnYjkN3UksC7P1BcBvXNWkw8C0zuJxrD OtqNxfcW1m58f3OvUzjmEbv9P+3JBbtGG71VBcBoPkBYZpYMR1d6yqn5ZHq/tTSgsf 2/oVbVs/s+WChZbe4hKxqftTGVrdZqYV7BbwlHcI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Johannes Thumshirn , =?UTF-8?q?Miquel=20Sabat=C3=A9=20Sol=C3=A0?= , David Sterba Subject: [PATCH 6.12 014/136] btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST Date: Tue, 21 Oct 2025 21:50:02 +0200 Message-ID: <20251021195036.311882431@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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: -1.9 (-) 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: (-1.9 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] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [147.75.80.249 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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: -18 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Miquel Sabaté Solà commit fec9b9d3ced39f16be8d7afdf81f4dd2653da319 upstream. At the end of btrfs_load_block_group_zone_info() the first thing we do is to ensure that if the mapping type is not a SINGLE one and there is no RAID stripe tree, then we return early with an error. Doing that, though, prevents the code from running the last calls from this function which are about freeing memory allocated during its run. Hence, in this case, instead of returning early, we set the ret value and fall through the rest of the cleanup code. Fixes: 5906333cc4af ("btrfs: zoned: don't skip block group profile checks on conventional zones") CC: stable@vger.kernel.org # 6.8+ Reviewed-by: Johannes Thumshirn Signed-off-by: Miquel Sabaté Solà Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/zoned.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/zoned.c +++ b/fs/btrfs/zoned.c @@ -1664,7 +1664,7 @@ out: !fs_info->stripe_root) { btrfs_err(fs_info, "zoned: data %s needs raid-stripe-tree", btrfs_bg_type_to_raid_name(map->type)); - return -EINVAL; + ret = -EINVAL; } if (cache->alloc_offset > cache->zone_capacity) { From - Tue Oct 21 19:58:39 2025 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 GNheBuzl92i95g4AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:36 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:36 +0000 Received: from sv.mirrors.kernel.org ([139.178.88.99]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIV9-00000004NdJ-30RY for hi@josie.lol; Tue, 21 Oct 2025 19:58:36 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 58E365808C8 for ; Tue, 21 Oct 2025 19:58:21 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0B8B6274B5A; Tue, 21 Oct 2025 19:58:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="PJfhag6C" 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 D99AF350A2A; Tue, 21 Oct 2025 19:58:19 +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=1761076699; cv=none; b=HoDA5fOee3xrTg1uhaUiHglFUd+uCqistzW0daxymagEyG7d3g1Hyz71WRkBp8vHGByrFtBDfAsRI4bVNTqGJf75clBt0AIu2Id3EHa4/1Xq/g1CiIMQCaDiInY7eEi1Ixuj+iG4QNqX3qOi6B50RNgV1d4dS6r4R0uQsXzihFc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076699; c=relaxed/simple; bh=D02AMEQXQ1Dcduqd2s9h8FK7nc4ui3EgNK6ZK5JL9dM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Dn8PpNNpRFIM9RNGUKukspxkELg2Chxxqd2Oq+TpSinbd6Q+frvGlC1JC/sAxTe/FvRQBSjr2Q9gaxxLIDhwBKEbm6whLyBAXLHjpSot1HIS8sr3dcE2LrppnUun2JP6YliZRLgKv31DZkkvH7S3gRQ847CLHtI0ymTTl39g74Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=PJfhag6C; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id E225BC4CEF1; Tue, 21 Oct 2025 19:58:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076699; bh=D02AMEQXQ1Dcduqd2s9h8FK7nc4ui3EgNK6ZK5JL9dM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PJfhag6CjiPLbyiFUx9bYyCEYHGWI8WLsZHunA+/4rXOCsOU1q32C1jYXYn3wFz+3 1vXkA8u1KjZe9Ze3rub9AErcKq5mjuBiAq2C5qByqioD8cjBlQ7iXhdf+EznNYM77Y HmloPLHqkwqNIxCAFTomDQYuAQoBXQlEmaYy54bE= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Boris Burkov , Johannes Thumshirn , Qu Wenruo , Filipe Manana , David Sterba Subject: [PATCH 6.12 011/136] btrfs: fix clearing of BTRFS_FS_RELOC_RUNNING if relocation already running Date: Tue, 21 Oct 2025 21:49:59 +0200 Message-ID: <20251021195036.233834777@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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. [139.178.88.99 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Filipe Manana commit 7e5a5983edda664e8e4bb20af17b80f5135c655c upstream. When starting relocation, at reloc_chunk_start(), if we happen to find the flag BTRFS_FS_RELOC_RUNNING is already set we return an error (-EINPROGRESS) to the callers, however the callers call reloc_chunk_end() which will clear the flag BTRFS_FS_RELOC_RUNNING, which is wrong since relocation was started by another task and still running. Finding the BTRFS_FS_RELOC_RUNNING flag already set is an unexpected scenario, but still our current behaviour is not correct. Fix this by never calling reloc_chunk_end() if reloc_chunk_start() has returned an error, which is what logically makes sense, since the general widespread pattern is to have end functions called only if the counterpart start functions succeeded. This requires changing reloc_chunk_start() to clear BTRFS_FS_RELOC_RUNNING if there's a pending cancel request. Fixes: 907d2710d727 ("btrfs: add cancellable chunk relocation support") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Boris Burkov Reviewed-by: Johannes Thumshirn Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/relocation.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -3906,6 +3906,7 @@ out: /* * Mark start of chunk relocation that is cancellable. Check if the cancellation * has been requested meanwhile and don't start in that case. + * NOTE: if this returns an error, reloc_chunk_end() must not be called. * * Return: * 0 success @@ -3922,10 +3923,8 @@ static int reloc_chunk_start(struct btrf if (atomic_read(&fs_info->reloc_cancel_req) > 0) { btrfs_info(fs_info, "chunk relocation canceled on start"); - /* - * On cancel, clear all requests but let the caller mark - * the end after cleanup operations. - */ + /* On cancel, clear all requests. */ + clear_and_wake_up_bit(BTRFS_FS_RELOC_RUNNING, &fs_info->flags); atomic_set(&fs_info->reloc_cancel_req, 0); return -ECANCELED; } @@ -3934,9 +3933,11 @@ static int reloc_chunk_start(struct btrf /* * Mark end of chunk relocation that is cancellable and wake any waiters. + * NOTE: call only if a previous call to reloc_chunk_start() succeeded. */ static void reloc_chunk_end(struct btrfs_fs_info *fs_info) { + ASSERT(test_bit(BTRFS_FS_RELOC_RUNNING, &fs_info->flags)); /* Requested after start, clear bit first so any waiters can continue */ if (atomic_read(&fs_info->reloc_cancel_req) > 0) btrfs_info(fs_info, "chunk relocation canceled during operation"); @@ -4145,9 +4146,9 @@ out: if (err && rw) btrfs_dec_block_group_ro(rc->block_group); iput(rc->data_inode); + reloc_chunk_end(fs_info); out_put_bg: btrfs_put_block_group(bg); - reloc_chunk_end(fs_info); free_reloc_control(rc); return err; } @@ -4331,8 +4332,8 @@ out_clean: ret = ret2; out_unset: unset_reloc_control(rc); -out_end: reloc_chunk_end(fs_info); +out_end: free_reloc_control(rc); out: free_reloc_roots(&reloc_roots); From - Tue Oct 21 19:58:45 2025 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 +K39KfHl92jAsg0AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:41 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:41 +0000 Received: from am.mirrors.kernel.org ([147.75.80.249]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVF-00000004Nl9-0Mxk for hi@josie.lol; Tue, 21 Oct 2025 19:58:41 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 3CDDA19C3BA0 for ; Tue, 21 Oct 2025 19:59:04 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B2958274B44; Tue, 21 Oct 2025 19:58:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="i8QIRgmN" 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 895AE246798; Tue, 21 Oct 2025 19:58:38 +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=1761076718; cv=none; b=kBvXwZ00kH1Zb7nQ6SFU5QI8ycCazmxJbmBHN6ArYhtlR+pjOS8SUMGImFyUUTFKumg3g4+DFLrj9IPl0mX628YiWWi7Feryc59CkFSppHHpjDQYZty6/3tH33vMvTVZ0B+U3DYqbmr0E7ltOo0dqhLH4+Wj3aw1edh6xbZSMjI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076718; c=relaxed/simple; bh=PWHT3C+JH+gTe8gQajgxPTk/Sz+bv9q8KTJ5ja0D5lU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KCnxOQZqmY7UW5H45KEuM1nij3Gz7xpdlkCaPwmKde99hqWq7t4Xg3Azjni0pBjcHMERLGPoicbHoO7haottnJ0cBfCAVPOylTkcbWlpd+JW3Bch5CumPNKn5WqPb6DPXzk2TKIQsaZcrrQgVanL8hK40EJtqQcCVcs65mOZ4/E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=i8QIRgmN; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2B3BC4CEF1; Tue, 21 Oct 2025 19:58:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076718; bh=PWHT3C+JH+gTe8gQajgxPTk/Sz+bv9q8KTJ5ja0D5lU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i8QIRgmNpshaJ3MBepHIyfnb4AHFQcBbb/DwY2f12n2O1dJVKCNxvRX+WukfpB77B yfpp42eVxfDFJ5RqWHYAhdYCxxhAnNbtoWoglRFpEKRA2tfy3m5/k3Toj6y2wjjSwV EvZHVC2VOjqDvAko0y2nh7YvlI9whz2NQKAp/nUM= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Runcheng Lu , Vincent Mailhol , Celeste Liu , Marc Kleine-Budde Subject: [PATCH 6.12 017/136] can: gs_usb: increase max interface to U8_MAX Date: Tue, 21 Oct 2025 21:50:05 +0200 Message-ID: <20251021195036.382627044@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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: -1.9 (-) 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: (-1.9 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] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [147.75.80.249 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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: -18 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Celeste Liu commit 2a27f6a8fb5722223d526843040f747e9b0e8060 upstream. This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu Cc: stable@vger.kernel.org Reviewed-by: Vincent Mailhol Signed-off-by: Celeste Liu Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacanthus.name Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman --- drivers/net/can/usb/gs_usb.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -286,11 +286,6 @@ struct gs_host_frame { #define GS_MAX_RX_URBS 30 #define GS_NAPI_WEIGHT 32 -/* Maximum number of interfaces the driver supports per device. - * Current hardware only supports 3 interfaces. The future may vary. - */ -#define GS_MAX_INTF 3 - struct gs_tx_context { struct gs_can *dev; unsigned int echo_id; @@ -321,7 +316,6 @@ struct gs_can { /* usb interface struct */ struct gs_usb { - struct gs_can *canch[GS_MAX_INTF]; struct usb_anchor rx_submitted; struct usb_device *udev; @@ -333,9 +327,11 @@ struct gs_usb { unsigned int hf_size_rx; u8 active_channels; + u8 channel_cnt; unsigned int pipe_in; unsigned int pipe_out; + struct gs_can *canch[] __counted_by(channel_cnt); }; /* 'allocate' a tx context. @@ -596,7 +592,7 @@ static void gs_usb_receive_bulk_callback } /* device reports out of range channel id */ - if (hf->channel >= GS_MAX_INTF) + if (hf->channel >= parent->channel_cnt) goto device_detach; dev = parent->canch[hf->channel]; @@ -696,7 +692,7 @@ resubmit_urb: /* USB failure take down all interfaces */ if (rc == -ENODEV) { device_detach: - for (rc = 0; rc < GS_MAX_INTF; rc++) { + for (rc = 0; rc < parent->channel_cnt; rc++) { if (parent->canch[rc]) netif_device_detach(parent->canch[rc]->netdev); } @@ -1458,17 +1454,19 @@ static int gs_usb_probe(struct usb_inter icount = dconf.icount + 1; dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); - if (icount > GS_MAX_INTF) { + if (icount > type_max(parent->channel_cnt)) { dev_err(&intf->dev, "Driver cannot handle more that %u CAN interfaces\n", - GS_MAX_INTF); + type_max(parent->channel_cnt)); return -EINVAL; } - parent = kzalloc(sizeof(*parent), GFP_KERNEL); + parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); if (!parent) return -ENOMEM; + parent->channel_cnt = icount; + init_usb_anchor(&parent->rx_submitted); usb_set_intfdata(intf, parent); @@ -1529,7 +1527,7 @@ static void gs_usb_disconnect(struct usb return; } - for (i = 0; i < GS_MAX_INTF; i++) + for (i = 0; i < parent->channel_cnt; i++) if (parent->canch[i]) gs_destroy_candev(parent->canch[i]); From - Tue Oct 21 19:58:48 2025 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 oGHgCfXl92jNLw8AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:45 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:45 +0000 Received: from sv.mirrors.kernel.org ([139.178.88.99]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVI-00000004Nr6-37OV for hi@josie.lol; Tue, 21 Oct 2025 19:58:45 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id EBB9F580AD7 for ; Tue, 21 Oct 2025 19:58:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9B17C273D66; Tue, 21 Oct 2025 19:58:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="zURl/BnR" 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 6B61E246798; Tue, 21 Oct 2025 19:58:32 +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=1761076712; cv=none; b=EG5Q0eW6I+advR38IhaqZVyuP4UiaB8g5opDt9XAhOVe9bAucwBJg4XDJAOhGZ2wKbA9x5nGbw5eSgxi5sfMAAZQkMXVUdpKWBBcfZ041IiBP9JYyX0UA0vdR+ocrrNjkKOFUflzyaDAr9NkSKipkfjWsKqdo6cJmdjwbJuX7hg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076712; c=relaxed/simple; bh=gw+H3P5wK0up8zWbM/KT9ykChVBOYIYavorhvO+dVi8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rXdwq6a04bjQ9SKCCdEfCs9fVyag0tSqsdJZBfyjWjwVVphfl9pPj4+qZ8ZjV5eQV85KT/GC/HVViNBZyGUl29CwVZE3yMuoJHBQHuW9wYD8S/WIeTqdOjKwuGxmPaJIRhn9PFbq9FalOP3NTc5CXvyyZweSEwwqniy6/ZURfHg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=zURl/BnR; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0A53C4CEF1; Tue, 21 Oct 2025 19:58:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076712; bh=gw+H3P5wK0up8zWbM/KT9ykChVBOYIYavorhvO+dVi8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zURl/BnRz0XjvRzZAlGqAqAerHbcxBP7DRBoggU/lPECSeYuloNXIx2HbaJjghNYN DSFY5hJSY67hpjsyqLPiy8XR6EVQSaC27ZuX+vO/U1HPNoS8nEiNAIx9xpNj37tgIJ FkQNKS3btIk9+3V6F5IGwV+wU/nBJoiBfEKKY+gI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, syzbot+884dc4621377ba579a6f@syzkaller.appspotmail.com, Qu Wenruo , Filipe Manana , David Sterba Subject: [PATCH 6.12 015/136] btrfs: do not assert we found block group item when creating free space tree Date: Tue, 21 Oct 2025 21:50:03 +0200 Message-ID: <20251021195036.336873953@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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: -1.9 (-) 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: (-1.9 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] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [139.178.88.99 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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: -18 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Filipe Manana commit a5a51bf4e9b7354ce7cd697e610d72c1b33fd949 upstream. Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]--- Reported-by: syzbot+884dc4621377ba579a6f@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/68dc3dab.a00a0220.102ee.004e.GAE@google.com/ Fixes: a5ed91828518 ("Btrfs: implement the free space B-tree") CC: # 6.1.x: 1961d20f6fa8: btrfs: fix assertion when building free space tree CC: # 6.1.x Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/free-space-tree.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) --- a/fs/btrfs/free-space-tree.c +++ b/fs/btrfs/free-space-tree.c @@ -1108,14 +1108,15 @@ static int populate_free_space_tree(stru * If ret is 1 (no key found), it means this is an empty block group, * without any extents allocated from it and there's no block group * item (key BTRFS_BLOCK_GROUP_ITEM_KEY) located in the extent tree - * because we are using the block group tree feature, so block group - * items are stored in the block group tree. It also means there are no - * extents allocated for block groups with a start offset beyond this - * block group's end offset (this is the last, highest, block group). + * because we are using the block group tree feature (so block group + * items are stored in the block group tree) or this is a new block + * group created in the current transaction and its block group item + * was not yet inserted in the extent tree (that happens in + * btrfs_create_pending_block_groups() -> insert_block_group_item()). + * It also means there are no extents allocated for block groups with a + * start offset beyond this block group's end offset (this is the last, + * highest, block group). */ - if (!btrfs_fs_compat_ro(trans->fs_info, BLOCK_GROUP_TREE)) - ASSERT(ret == 0); - start = block_group->start; end = block_group->start + block_group->length; while (ret == 0) { From - Tue Oct 21 19:58:52 2025 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 oB4MCPnl92ioFA4AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:49 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:49 +0000 Received: from sv.mirrors.kernel.org ([139.178.88.99]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVM-00000004O0H-2vb5 for hi@josie.lol; Tue, 21 Oct 2025 19:58:48 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 983E63AF3B5 for ; Tue, 21 Oct 2025 19:58:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E05C7274652; Tue, 21 Oct 2025 19:58:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="cEMnObTh" 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 BA878350A2A; Tue, 21 Oct 2025 19:58:35 +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=1761076715; cv=none; b=m/LYmOPhf14Rr1o5CiHGC0RTbOaM6tCQ1kTeYAk50/39jFKzZimgXDaobVEKqqxDykIaDulYVXKraBfpUv8IV6yoWefodiBKW1PNjP5e9BEdK8lwJSeR53wce2InTFG400RG6scPLwGTfVzkpU7SX9XL5aX0x2jel+wa8Z9uUjo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076715; c=relaxed/simple; bh=HdyNQFjPSMQJco02pCif69zU5FJSCk/90MtXEqtpqpI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=g51zXjbHk+prndlGHzU83cIgX64RnCfPhq4FpPPFTV4LZGX/oTuSSAxDCPx6VbouzB3Aua33UZ/ZjsK81Kcc2DePjWvj3/Dr+QuE9zvzd2AT8AYLD+czFv2ro8g5xIfLLvAdRiyA2cSQF+uGjB/MLaZOE3okynADSecHiIYMumw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=cEMnObTh; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC78AC4CEF1; Tue, 21 Oct 2025 19:58:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076715; bh=HdyNQFjPSMQJco02pCif69zU5FJSCk/90MtXEqtpqpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cEMnObTh43iJwV166tPvPNZnZX/7CQfRInQOjwjG+8cDBo9KruZueZ9LJC5U+CE5J HMNjwZNHPNj3GjRjEegW/rMyuse9qllChfBABHovMlFKtqkUKviJBhDfue95dB1pbF sVL9SNqufZ0Bll6ShDFZx28siCLApJhQ7vPaoC2M= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Celeste Liu , Marc Kleine-Budde Subject: [PATCH 6.12 016/136] can: gs_usb: gs_make_candev(): populate net_device->dev_port Date: Tue, 21 Oct 2025 21:50:04 +0200 Message-ID: <20251021195036.359872197@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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: msgid.link] 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. [139.178.88.99 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Celeste Liu commit a12f0bc764da3781da2019c60826f47a6d7ed64f upstream. The gs_usb driver supports USB devices with more than 1 CAN channel. In old kernel before 3.15, it uses net_device->dev_id to distinguish different channel in userspace, which was done in commit acff76fa45b4 ("can: gs_usb: gs_make_candev(): set netdev->dev_id"). But since 3.15, the correct way is populating net_device->dev_port. And according to documentation, if network device support multiple interface, lack of net_device->dev_port SHALL be treated as a bug. Fixes: acff76fa45b4 ("can: gs_usb: gs_make_candev(): set netdev->dev_id") Cc: stable@vger.kernel.org Signed-off-by: Celeste Liu Link: https://patch.msgid.link/20250930-gs-usb-populate-net_device-dev_port-v1-1-68a065de6937@coelacanthus.name Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman --- drivers/net/can/usb/gs_usb.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -1246,6 +1246,7 @@ static struct gs_can *gs_make_candev(uns netdev->flags |= IFF_ECHO; /* we support full roundtrip echo */ netdev->dev_id = channel; + netdev->dev_port = channel; /* dev setup */ strcpy(dev->bt_const.name, KBUILD_MODNAME); From - Tue Oct 21 19:58:56 2025 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 YI7MJvrl92i95g4AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:50 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:50 +0000 Received: from am.mirrors.kernel.org ([147.75.80.249]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVN-00000004O15-3e5p for hi@josie.lol; Tue, 21 Oct 2025 19:58:50 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id F1BB719C3C14 for ; Tue, 21 Oct 2025 19:59:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8C0BD274652; Tue, 21 Oct 2025 19:58:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="N/B94UaS" 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 640BB350A2A; Tue, 21 Oct 2025 19:58:45 +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=1761076725; cv=none; b=WLqh0ZMi4PE+V0hNJpcMX4dtBKOEtEJU9BfiA27o0X3P2fITmpM3SEqD7PO61u3RZwxwdSviEkAdXzhyDBrouEDExe6Rq4TVm2uxrIFcJs3nu945ZSOpq90RWWJorGFD1lcgVfe/L5BUiIm9KzVhvuOKQlA3nQkXjzqNVnsf6lU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076725; c=relaxed/simple; bh=lgF9mJJEjPvWE+fRFBluqkbkZbVvQUs0Bu4RIwgbDsY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OqbRlj5Y5A+6uNMLZdbNSNPKeR6z2HZjMa2VN6/T0uaP5jXa6bNqv+ace2JG691Klkvtqu5YN91CoP5YJHJavegmh6B7Fh1oHN8Kh30Dynzk+ILp8XIGb1jObIOv+BhHODpAwkhvMZMwGJ0z4auR8xbtH6mi6qcqzVcBKpfRI64= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=N/B94UaS; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B96EC4CEF1; Tue, 21 Oct 2025 19:58:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076725; bh=lgF9mJJEjPvWE+fRFBluqkbkZbVvQUs0Bu4RIwgbDsY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N/B94UaSeef7HF7/3/2UPrfRKAxXKWdodBcYewIYkGDA4nUNlOHVpzVzkS/5S1fM7 Rb1bszSYcLpYQ1wNzX7PDkqqWt0H9sezWpnNT8muDk6xinhWCar9TlDtBmtVyKyDst gQwiB1ACGl3WwEEvnsAr7nLIrlc5HwspYGvQ2E74= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Tvrtko Ursulin , Dan Carpenter , =?UTF-8?q?Christian=20K=C3=B6nig?= , Rob Clark , Daniel Vetter , Matthew Brost , Danilo Krummrich , Philipp Stanner , =?UTF-8?q?Christian=20K=C3=B6nig?= , dri-devel@lists.freedesktop.org Subject: [PATCH 6.12 019/136] drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies Date: Tue, 21 Oct 2025 21:50:07 +0200 Message-ID: <20251021195036.432183305@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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] 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. [147.75.80.249 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tvrtko Ursulin commit 5801e65206b065b0b2af032f7f1eef222aa2fd83 upstream. When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free. Interestingly this bug appears to have been present ever since commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code back then looked like this: drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]); Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it. The bug was then only noticed and fixed after commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") landed, with its fixup of commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies"). At that point it was a slightly different flavour of a double free, which commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") noticed and attempted to fix. But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case. As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain. While fixing we also improve the comment and explain the reason for taking the reference and not dropping it. Signed-off-by: Tvrtko Ursulin Fixes: 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/dri-devel/aNFbXq8OeYl3QSdm@stanley.mountain/ Cc: Christian König Cc: Rob Clark Cc: Daniel Vetter Cc: Matthew Brost Cc: Danilo Krummrich Cc: Philipp Stanner Cc: Christian König Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v5.16+ Signed-off-by: Philipp Stanner Link: https://lore.kernel.org/r/20251015084015.6273-1-tvrtko.ursulin@igalia.com Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/scheduler/sched_main.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -952,13 +952,14 @@ int drm_sched_job_add_resv_dependencies( dma_resv_assert_held(resv); dma_resv_for_each_fence(&cursor, resv, usage, fence) { - /* Make sure to grab an additional ref on the added fence */ - dma_fence_get(fence); - ret = drm_sched_job_add_dependency(job, fence); - if (ret) { - dma_fence_put(fence); + /* + * As drm_sched_job_add_dependency always consumes the fence + * reference (even when it fails), and dma_resv_for_each_fence + * is not obtaining one, we need to grab one before calling. + */ + ret = drm_sched_job_add_dependency(job, dma_fence_get(fence)); + if (ret) return ret; - } } return 0; } From - Tue Oct 21 19:58:56 2025 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 KJ47Ev3l92gsiQ4AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:53 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:53 +0000 Received: from sv.mirrors.kernel.org ([139.178.88.99]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVQ-00000004O6J-27gX for hi@josie.lol; Tue, 21 Oct 2025 19:58:52 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 7417B48487D for ; Tue, 21 Oct 2025 19:58:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 25C1E274652; Tue, 21 Oct 2025 19:58:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ik1awKbV" 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 EEF98246798; Tue, 21 Oct 2025 19:58:41 +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=1761076722; cv=none; b=kuSZcQZduPi+XGqaej7wBshKKC/MYP1uAmsqdOHbqCEHE4i8O9F/XWb+UKtTwR41IkC5iofuMMmsMARoDaep3Kjmm194NY1XKQ6uA+5+8Dd60KINXltcFwIHEanOq1dbkK7i0gTzsgib8DNcbRd0THLiF/rc9ZWPVZ8g7Bjopvg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076722; c=relaxed/simple; bh=W4iJNIzwg2zailRI9LlwlYvc4v/qpI4O3ML2UG28XWY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=E/RfT0LIoZ36JniHLcgceLRLWCfW6wBYiiPh4QZs7+O1d2g5Ry5BTKJgNtZFMxZIVsPoH+T9mKxM04BZ8wAkFUChY5yAkkpmmi1kokT8Ul2Jg8Z7Zvw3p/mcF56LM8KVTc4RF3ecMuHCTciGbbLGgRQVuWMij5tDtwuI+zXNXxQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ik1awKbV; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E5FBC4CEF1; Tue, 21 Oct 2025 19:58:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076721; bh=W4iJNIzwg2zailRI9LlwlYvc4v/qpI4O3ML2UG28XWY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ik1awKbVc+HMKnXaPNSpr4ljhG50yG6cVtVrz8MRQWKsYsfQe8FMeSG6fxTiVIrxt KgaNOIipy1ZCAfpFlwrwJ1kyqqsYka+vovm6jYgtSAzpZ0Wn/pZP+krqH+K+NQG5AY jmygQWPDd7tr4eq2xtI+ufUyah6Ng24S3IqQSFYo= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Eugene Korenevsky , Nathan Chancellor , "Paulo Alcantara (Red Hat)" , Steve French Subject: [PATCH 6.12 018/136] cifs: parse_dfs_referrals: prevent oob on malformed input Date: Tue, 21 Oct 2025 21:50:06 +0200 Message-ID: <20251021195036.406937686@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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_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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 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. [139.178.88.99 listed in list.dnswl.org] -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 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eugene Korenevsky commit 6447b0e355562a1ff748c4a2ffb89aae7e84d2c9 upstream. Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS - reply smaller than sizeof(struct get_dfs_referral_rsp) - reply with number of referrals smaller than NumberOfReferrals in the header Processing of such replies will cause oob. Return -EINVAL error on such replies to prevent oob-s. Signed-off-by: Eugene Korenevsky Cc: stable@vger.kernel.org Suggested-by: Nathan Chancellor Acked-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman --- fs/smb/client/misc.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) --- a/fs/smb/client/misc.c +++ b/fs/smb/client/misc.c @@ -913,6 +913,14 @@ parse_dfs_referrals(struct get_dfs_refer char *data_end; struct dfs_referral_level_3 *ref; + if (rsp_size < sizeof(*rsp)) { + cifs_dbg(VFS | ONCE, + "%s: header is malformed (size is %u, must be %zu)\n", + __func__, rsp_size, sizeof(*rsp)); + rc = -EINVAL; + goto parse_DFS_referrals_exit; + } + *num_of_nodes = le16_to_cpu(rsp->NumberOfReferrals); if (*num_of_nodes < 1) { @@ -921,6 +929,15 @@ parse_dfs_referrals(struct get_dfs_refer rc = -EINVAL; goto parse_DFS_referrals_exit; } + + if (sizeof(*rsp) + *num_of_nodes * sizeof(REFERRAL3) > rsp_size) { + cifs_dbg(VFS | ONCE, + "%s: malformed buffer (size is %u, must be at least %zu)\n", + __func__, rsp_size, + sizeof(*rsp) + *num_of_nodes * sizeof(REFERRAL3)); + rc = -EINVAL; + goto parse_DFS_referrals_exit; + } ref = (struct dfs_referral_level_3 *) &(rsp->referrals); if (ref->VersionNumber != cpu_to_le16(3)) { From - Tue Oct 21 19:58:59 2025 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 MEK4Av/l92gsiQ4AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:55 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:55 +0000 Received: from dfw.mirrors.kernel.org ([142.0.200.124]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVS-00000004O7X-2ELx for hi@josie.lol; Tue, 21 Oct 2025 19:58:54 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.mirrors.kernel.org (Postfix) with ESMTPS id A43714F7DD1 for ; Tue, 21 Oct 2025 19:58:53 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1E3AF274B30; Tue, 21 Oct 2025 19:58:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="XyjSFsDM" 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 E8FE2246798; Tue, 21 Oct 2025 19:58:50 +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=1761076731; cv=none; b=qdIFmn7Oe97ZOjNXo6xw/cbTOk5fR5ggIPFUj/ObiLw7gjPkAlEhsqNRa/VFsSrGYhhU1VJX8sDY+j6G5mRe9cTh7Th6yfa0EPbR+R97rEXYu5QHU1rjxRtNUV6uGIW2n/qMWnbM02bTvwnfUfWTzu3z8fAolE/nllO00Eh0160= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076731; c=relaxed/simple; bh=UOIsUDf0bWg8bN5aUvYoKqc7KkF+Lv7GW7IFuztqZ80=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ddSXJRuyeuNFW553A4u7db+QVAkWpA2S0sAu/cpDRrcesP3FW0CszXxLPv0Xo0Ng1oDYix1PFFec6FKb+Sfl1eV4rlTNhaHcfLhgTUjJqlGmOwqNNiWlFuNcq/wYpJMeK7lG17iYcAPJyeV0mDlQ3KmqTJPz0FKOvmsHxmH5AEc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=XyjSFsDM; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7680EC4CEF7; Tue, 21 Oct 2025 19:58:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076730; bh=UOIsUDf0bWg8bN5aUvYoKqc7KkF+Lv7GW7IFuztqZ80=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XyjSFsDM0HQPYjwtrnl1mFkUVc8346ZjDY2+K+VCzlIogXo9COM6QOU9wHLiitfmV WrFgUxxZYxzJ8h/hAwZjs4SG5x5mm66ibe0mgPtTT39ZxicTiihvUrb5kkIw5LmO52 yKeQjYx9nOqL5j1M1tHFCaLbcIs1k4HiFD2RL/14= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Thomas Zimmermann , Nick Bowler , Douglas Anderson , Dave Airlie , Jocelyn Falempe , dri-devel@lists.freedesktop.org Subject: [PATCH 6.12 020/136] drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off Date: Tue, 21 Oct 2025 21:50:08 +0200 Message-ID: <20251021195036.457336682@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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. [142.0.200.124 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Zimmermann commit 6f719373b943a955fee6fc2012aed207b65e2854 upstream. Blank the display by disabling sync pulses with VGACR17<7>. Unblank by reenabling them. This VGA setting should be supported by all Aspeed hardware. Ast currently blanks via sync-off bits in VGACRB6. Not all BMCs handle VGACRB6 correctly. After disabling sync during a reboot, some BMCs do not reenable it after the soft reset. The display output remains dark. When the display is off during boot, some BMCs set the sync-off bits in VGACRB6, so the display remains dark. Observed with Blackbird AST2500 BMCs. Clearing the sync-off bits unconditionally fixes these issues. Also do not modify VGASR1's SD bit for blanking, as it only disables GPU access to video memory. v2: - init vgacrb6 correctly (Jocelyn) Signed-off-by: Thomas Zimmermann Fixes: ce3d99c83495 ("drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers") Tested-by: Nick Bowler Reported-by: Nick Bowler Closes: https://lore.kernel.org/dri-devel/wpwd7rit6t4mnu6kdqbtsnk5bhftgslio6e2jgkz6kgw6cuvvr@xbfswsczfqsi/ Cc: Douglas Anderson Cc: Dave Airlie Cc: Thomas Zimmermann Cc: Jocelyn Falempe Cc: dri-devel@lists.freedesktop.org Cc: # v6.7+ Reviewed-by: Jocelyn Falempe Link: https://lore.kernel.org/r/20251014084743.18242-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/ast/ast_mode.c | 18 ++++++++++-------- drivers/gpu/drm/ast/ast_reg.h | 1 + 2 files changed, 11 insertions(+), 8 deletions(-) --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -1195,22 +1195,24 @@ ast_crtc_helper_atomic_flush(struct drm_ static void ast_crtc_helper_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct ast_device *ast = to_ast_device(crtc->dev); + u8 vgacr17 = 0x00; + u8 vgacrb6 = 0xff; - ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, 0x00); - ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, 0x00); + vgacr17 |= AST_IO_VGACR17_SYNC_ENABLE; + vgacrb6 &= ~(AST_IO_VGACRB6_VSYNC_OFF | AST_IO_VGACRB6_HSYNC_OFF); + + ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17); + ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6); } static void ast_crtc_helper_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct drm_crtc_state *old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc); struct ast_device *ast = to_ast_device(crtc->dev); - u8 vgacrb6; + u8 vgacr17 = 0xff; - ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, AST_IO_VGASR1_SD); - - vgacrb6 = AST_IO_VGACRB6_VSYNC_OFF | - AST_IO_VGACRB6_HSYNC_OFF; - ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6); + vgacr17 &= ~AST_IO_VGACR17_SYNC_ENABLE; + ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17); /* * HW cursors require the underlying primary plane and CRTC to --- a/drivers/gpu/drm/ast/ast_reg.h +++ b/drivers/gpu/drm/ast/ast_reg.h @@ -29,6 +29,7 @@ #define AST_IO_VGAGRI (0x4E) #define AST_IO_VGACRI (0x54) +#define AST_IO_VGACR17_SYNC_ENABLE BIT(7) /* called "Hardware reset" in docs */ #define AST_IO_VGACR80_PASSWORD (0xa8) #define AST_IO_VGACRA1_VGAIO_DISABLED BIT(1) #define AST_IO_VGACRA1_MMIO_ENABLED BIT(2) From - Tue Oct 21 19:59:03 2025 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 KHF7EwLm92jm6A8AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:58 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:58 +0000 Received: from sv.mirrors.kernel.org ([139.178.88.99]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVV-00000004ODC-33Aj for hi@josie.lol; Tue, 21 Oct 2025 19:58:58 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 4AEA43AA37C for ; Tue, 21 Oct 2025 19:58:52 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 93D5D274652; Tue, 21 Oct 2025 19:58:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="f3/1uUI9" 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 6B6D2246798; Tue, 21 Oct 2025 19:58: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=1761076730; cv=none; b=IMMel1+npeTHi6J+hshARDRMslOwlsOXBlvzqAbml7WeRSbr53y5OpfSVzI6ebCk4CgRDRBD28mylyO5Y88ZJPydYkJSCu1Wp6XfWRIibVLlJ24LZKr1WvThdOKh3UHterSFfy2JqfjQ3LwERP98we1WkuQHK8A7EBVhkdY+7Nc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076730; c=relaxed/simple; bh=z8WVqxBFbgDsHuNLgM1FHAPfqSB61aw9dmomFUgLXqs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eVxqIabmCgCw4ULLDX6hMRyFg2/6h+lXZcl6vYn5GMx9kLkkr1DSNcE0ITOMrS183atfn8mzDsE8YJVPJdNrpjm1nmOmA0TlwzOVWH5tdcIm9vrkzZvycqyazDaEpsk2NYDHEu9Uc5CuFEWrIKTFA6/c3/plYFHkxN+ouJXSeCY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=f3/1uUI9; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5023C4CEF1; Tue, 21 Oct 2025 19:58:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076728; bh=z8WVqxBFbgDsHuNLgM1FHAPfqSB61aw9dmomFUgLXqs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f3/1uUI9zu1rK1mYdBVPJJcCrn78vxavAe7/Dfjfbr5S5Ymfgi4rqLDKFnhLNSRlR kAwne4qCNhMlmfRC9bU40AEv6qAKlGRndrba5T1RptUoawfrKUkLuahWyvNNsEtb3C XP/qTuGf0DVSIK+6N6vKnSWnO+xZxAa5Fwq8hfFs= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Conor Dooley , Miguel Ojeda , Alice Ryhl , Paul Walmsley Subject: [PATCH 6.12 002/136] rust: cfi: only 64-bit arm and x86 support CFI_CLANG Date: Tue, 21 Oct 2025 21:49:50 +0200 Message-ID: <20251021195036.014512641@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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: -1.9 (-) 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: (-1.9 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] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [139.178.88.99 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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: -18 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Conor Dooley commit 812258ff4166bcd41c7d44707e0591f9ae32ac8c upstream. The kernel uses the standard rustc targets for non-x86 targets, and out of those only 64-bit arm's target has kcfi support enabled. For x86, the custom 64-bit target enables kcfi. The HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC config option that allows CFI_CLANG to be used in combination with RUST does not check whether the rustc target supports kcfi. This breaks the build on riscv (and presumably 32-bit arm) when CFI_CLANG and RUST are enabled at the same time. Ordinarily, a rustc-option check would be used to detect target support but unfortunately rustc-option filters out the target for reasons given in commit 46e24a545cdb4 ("rust: kasan/kbuild: fix missing flags on first build"). As a result, if the host supports kcfi but the target does not, e.g. when building for riscv on x86_64, the build would remain broken. Instead, make HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC depend on the only two architectures where the target used supports it to fix the build. CC: stable@vger.kernel.org Fixes: ca627e636551e ("rust: cfi: add support for CFI_CLANG with Rust") Signed-off-by: Conor Dooley Acked-by: Miguel Ojeda Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250908-distill-lint-1ae78bcf777c@spud Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman --- arch/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/arch/Kconfig +++ b/arch/Kconfig @@ -861,6 +861,7 @@ config HAVE_CFI_ICALL_NORMALIZE_INTEGERS def_bool y depends on HAVE_CFI_ICALL_NORMALIZE_INTEGERS_CLANG depends on RUSTC_VERSION >= 107900 + depends on ARM64 || X86_64 # With GCOV/KASAN we need this fix: https://github.com/rust-lang/rust/pull/129373 depends on (RUSTC_LLVM_VERSION >= 190103 && RUSTC_VERSION >= 108200) || \ (!GCOV_KERNEL && !KASAN_GENERIC && !KASAN_SW_TAGS) From - Tue Oct 21 19:59:03 2025 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 iMTYIAPm92i95g4AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:58:59 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:58:59 +0000 Received: from am.mirrors.kernel.org ([147.75.80.249]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVW-00000004OEY-3qg9 for hi@josie.lol; Tue, 21 Oct 2025 19:58:59 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 0545A19C3CAD for ; Tue, 21 Oct 2025 19:59:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ACBCF274B2E; Tue, 21 Oct 2025 19:58:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Xii6aHaU" 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 84C7A274652; Tue, 21 Oct 2025 19:58:54 +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=1761076734; cv=none; b=fUqNJ3RCbCF8+90/BXWt6VQ36jzcnq5cG/TqA72XbwmJnPrZp9mCPKaVRBJi4BjYw51Jz7vrViHbj9w+1GAvWOXX+aG9UAHRtlmnsQ9hGnrcuUtgHd4mZaEKfkfso/ipFNJd3pF/FvoLqqkhjuFO9q5RmRqzPYvsKwPNf2K87UM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076734; c=relaxed/simple; bh=Mb3hzVQjNGYG+ZCBzv2DShmiJmAW9U1kKJY+dYcx3kw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JbWu3lDbMsAArDoMthdENMz8LupxWbZKbtAftnzeBgmfcU7ZCeNVsJGBn3WDOE9rld3tAgzB4VHCvASVMzMcB2uEDrgV4O7UYLWasBigbfe4zt/lXZKmMA6d2LWdAeyGO8hJdIjVSC5v5bn9wjl15VP0kd1HmV2QWFzdcdWDFpM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Xii6aHaU; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id E354DC116B1; Tue, 21 Oct 2025 19:58:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076734; bh=Mb3hzVQjNGYG+ZCBzv2DShmiJmAW9U1kKJY+dYcx3kw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Xii6aHaUf913eBI3/o6BAfjqTZyP1roNaX9A5qrZy7Dqo0cECRX4vLnGg+p6v5lxu xUCDVaLUdq8MrKvPfZSNyORmBPP+WL/vLl0AM3JSKUXayu35tUtgUh6xlitkQkw8kC uPRHpFEY/rNM36FdEUQ/dKIFCOWepzAaUEqh2mn8= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Gui-Dong Han , Felix Kuehling , Alex Deucher Subject: [PATCH 6.12 021/136] drm/amdgpu: use atomic functions with memory barriers for vm fault info Date: Tue, 21 Oct 2025 21:50:09 +0200 Message-ID: <20251021195036.484778431@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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: -1.9 (-) 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: (-1.9 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] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [147.75.80.249 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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: -18 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Gui-Dong Han commit 6df8e84aa6b5b1812cc2cacd6b3f5ccbb18cda2b upstream. The atomic variable vm_fault_info_updated is used to synchronize access to adev->gmc.vm_fault_info between the interrupt handler and get_vm_fault_info(). The default atomic functions like atomic_set() and atomic_read() do not provide memory barriers. This allows for CPU instruction reordering, meaning the memory accesses to vm_fault_info and the vm_fault_info_updated flag are not guaranteed to occur in the intended order. This creates a race condition that can lead to inconsistent or stale data being used. The previous implementation, which used an explicit mb(), was incomplete and inefficient. It failed to account for all potential CPU reorderings, such as the access of vm_fault_info being reordered before the atomic_read of the flag. This approach is also more verbose and less performant than using the proper atomic functions with acquire/release semantics. Fix this by switching to atomic_set_release() and atomic_read_acquire(). These functions provide the necessary acquire and release semantics, which act as memory barriers to ensure the correct order of operations. It is also more efficient and idiomatic than using explicit full memory barriers. Fixes: b97dfa27ef3a ("drm/amdgpu: save vm fault information for amdkfd") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 ++--- drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 7 +++---- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 7 +++---- 3 files changed, 8 insertions(+), 11 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c @@ -2353,10 +2353,9 @@ void amdgpu_amdkfd_gpuvm_unmap_gtt_bo_fr int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct amdgpu_device *adev, struct kfd_vm_fault_info *mem) { - if (atomic_read(&adev->gmc.vm_fault_info_updated) == 1) { + if (atomic_read_acquire(&adev->gmc.vm_fault_info_updated) == 1) { *mem = *adev->gmc.vm_fault_info; - mb(); /* make sure read happened */ - atomic_set(&adev->gmc.vm_fault_info_updated, 0); + atomic_set_release(&adev->gmc.vm_fault_info_updated, 0); } return 0; } --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c @@ -1055,7 +1055,7 @@ static int gmc_v7_0_sw_init(void *handle GFP_KERNEL); if (!adev->gmc.vm_fault_info) return -ENOMEM; - atomic_set(&adev->gmc.vm_fault_info_updated, 0); + atomic_set_release(&adev->gmc.vm_fault_info_updated, 0); return 0; } @@ -1287,7 +1287,7 @@ static int gmc_v7_0_process_interrupt(st vmid = REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS, VMID); if (amdgpu_amdkfd_is_kfd_vmid(adev, vmid) - && !atomic_read(&adev->gmc.vm_fault_info_updated)) { + && !atomic_read_acquire(&adev->gmc.vm_fault_info_updated)) { struct kfd_vm_fault_info *info = adev->gmc.vm_fault_info; u32 protections = REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS, @@ -1303,8 +1303,7 @@ static int gmc_v7_0_process_interrupt(st info->prot_read = protections & 0x8 ? true : false; info->prot_write = protections & 0x10 ? true : false; info->prot_exec = protections & 0x20 ? true : false; - mb(); - atomic_set(&adev->gmc.vm_fault_info_updated, 1); + atomic_set_release(&adev->gmc.vm_fault_info_updated, 1); } return 0; --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c @@ -1168,7 +1168,7 @@ static int gmc_v8_0_sw_init(void *handle GFP_KERNEL); if (!adev->gmc.vm_fault_info) return -ENOMEM; - atomic_set(&adev->gmc.vm_fault_info_updated, 0); + atomic_set_release(&adev->gmc.vm_fault_info_updated, 0); return 0; } @@ -1468,7 +1468,7 @@ static int gmc_v8_0_process_interrupt(st vmid = REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS, VMID); if (amdgpu_amdkfd_is_kfd_vmid(adev, vmid) - && !atomic_read(&adev->gmc.vm_fault_info_updated)) { + && !atomic_read_acquire(&adev->gmc.vm_fault_info_updated)) { struct kfd_vm_fault_info *info = adev->gmc.vm_fault_info; u32 protections = REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS, @@ -1484,8 +1484,7 @@ static int gmc_v8_0_process_interrupt(st info->prot_read = protections & 0x8 ? true : false; info->prot_write = protections & 0x10 ? true : false; info->prot_exec = protections & 0x20 ? true : false; - mb(); - atomic_set(&adev->gmc.vm_fault_info_updated, 1); + atomic_set_release(&adev->gmc.vm_fault_info_updated, 1); } return 0; From - Tue Oct 21 19:59:06 2025 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 YOb0Dwbm92iKYg4AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:59:02 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:59:02 +0000 Received: from am.mirrors.kernel.org ([147.75.80.249]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVZ-00000004OJG-3YjN for hi@josie.lol; Tue, 21 Oct 2025 19:59:02 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id DF6C119C3DFE for ; Tue, 21 Oct 2025 19:59:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6112D274652; Tue, 21 Oct 2025 19:58:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="a3vqsbfH" 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 3AA07350A2A; Tue, 21 Oct 2025 19:58:58 +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=1761076738; cv=none; b=BkqpZN8QeSCz9iHh+CZNBmvaVjOUbwcfU1rUyUpuorcAmL2tHo41jPtZJHEb7QUmhFSeCcyKHTIp/pPvO1l1l/+mRgjOQ1hi+9rbSNiS2NhXdaP5eXrL8PuWGGfDo+zJDYgcZK+DZaCKRKGeB3b5z5u+TpawLIxe187g7hgvRgs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076738; c=relaxed/simple; bh=p7EpDIzG+Cg/4SBzsJVJpXnelA2QTEvYvNhgULeOBgI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ghpq8A+O40/eqkDMso0SRxCwCJ5gF8IZB+v8GLtJ+o76Nzt/eGR0Mq07TSXdqxcYguT0ZpYhdoxYv9AsgU7+0YAIvjhgC/wouuMq7B12w2nwa6VnDqajO7EQOFwIFEQMFXMTIKp8+bIRDz+Atw4equ/Pli8aBy2E9ayy8Hhq3Z4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=a3vqsbfH; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A0D9C4CEF1; Tue, 21 Oct 2025 19:58:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076737; bh=p7EpDIzG+Cg/4SBzsJVJpXnelA2QTEvYvNhgULeOBgI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a3vqsbfH4lU3KFgz1mb8bXPf5S+27VrxBdvpvzIsxJsZktSCZ9D53mOrk/f1JiJmt sjuh0QxFBvqWP78CmV5p/k1NvbU0FIXrlATsKbm9y3n0vYR6yOTMVNl22+5qrSEks8 q6xIrXkVpFo/j8UsztOuv3sQK1hkDM5HSzBStywU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Jonathan Kim , Alex Deucher Subject: [PATCH 6.12 022/136] drm/amdgpu: fix gfx12 mes packet status return check Date: Tue, 21 Oct 2025 21:50:10 +0200 Message-ID: <20251021195036.508383897@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@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: -1.9 (-) 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: (-1.9 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] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [147.75.80.249 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -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 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -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: -18 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jonathan Kim commit d0de79f66a80eeb849033fae34bd07a69ce72235 upstream. GFX12 MES uses low 32 bits of status return for success (1 or 0) and high bits for debug information if low bits are 0. GFX11 MES doesn't do this so checking full 64-bit status return for 1 or 0 is still valid. Signed-off-by: Jonathan Kim Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/amd/amdgpu/mes_v12_0.c +++ b/drivers/gpu/drm/amd/amdgpu/mes_v12_0.c @@ -224,7 +224,12 @@ static int mes_v12_0_submit_pkt_and_poll pipe, x_pkt->header.opcode); r = amdgpu_fence_wait_polling(ring, seq, timeout); - if (r < 1 || !*status_ptr) { + + /* + * status_ptr[31:0] == 0 (fail) or status_ptr[63:0] == 1 (success). + * If status_ptr[31:0] == 0 then status_ptr[63:32] will have debug error information. + */ + if (r < 1 || !(lower_32_bits(*status_ptr))) { if (misc_op_str) dev_err(adev->dev, "MES(%d) failed to respond to msg=%s (%s)\n", From - Tue Oct 21 19:59:09 2025 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 cB3fLgrm92ioFA4AYBR5ng (envelope-from ) for ; Tue, 21 Oct 2025 19:59:06 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 21 Oct 2025 19:59:06 +0000 Received: from dfw.mirrors.kernel.org ([142.0.200.124]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vBIVe-00000004OVG-1BEA for hi@josie.lol; Tue, 21 Oct 2025 19:59:06 +0000 Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.mirrors.kernel.org (Postfix) with ESMTPS id 2B2444F81D5 for ; Tue, 21 Oct 2025 19:59:05 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 99251274652; Tue, 21 Oct 2025 19:59:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="OHxsrVHd" 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 71302273D66; Tue, 21 Oct 2025 19:59:04 +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=1761076744; cv=none; b=gZayNcRWhKjJKWOPjF1sniScMTOJfqtkVviuCKn9tVbnpcM/vKbtNrFIArKOb+Wq2q4kxH6d1sLZ1fxzGu+nXOIhPFUNBXNkPgLTCI31y4D3fILMpqXoCBU0Baglqha3WYwYgWIK7x2CyZlPqlr+cyRFWVcjhx9mvm1TWbqSTuQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076744; c=relaxed/simple; bh=3d1k5ppOAi9cFt/wvduHYBQFqP0dmFpwG2fNu7Mn2pY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PRSvLXIXBbHMi+YFH0BPpVxgH7+4bh5fOlkaFvEqX3e4CtnkesPxXH9xC+lhtZcS+9cHpRVFPwu2o7mBwWZjigheKjngO1/nEs0OMX2XT14eYDEspEkwiOp8CJqDzkgJJQcD96WScPCpKBWeEKrgqaDcBuOla25voraVG9uUamE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=OHxsrVHd; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A5A2C4CEF1; Tue, 21 Oct 2025 19:59:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076744; bh=3d1k5ppOAi9cFt/wvduHYBQFqP0dmFpwG2fNu7Mn2pY=; h=From:To:Cc:Subject:Da