lid DKIM or DK signature from author's domain -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [URIs: gnu.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: -11 From: Cupertino Miranda [ Upstream commit d18dec4b8990048ce75f0ece32bb96b3fbd3f422 ] This patch improves the verifier to correctly compute bounds for sign extension compiler pattern composed of left shift by 32bits followed by a sign right shift by 32bits. Pattern in the verifier was limitted to positive value bounds and would reset bound computation for negative values. New code allows both positive and negative values for sign extension without compromising bound computation and verifier to pass. This change is required by GCC which generate such pattern, and was detected in the context of systemd, as described in the following GCC bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119731 Three new tests were added in verifier_subreg.c. Signed-off-by: Cupertino Miranda Signed-off-by: Andrew Pinski Acked-by: Eduard Zingerman Cc: David Faust Cc: Jose Marchesi Cc: Elena Zannoni Link: https://lore.kernel.org/r/20251202180220.11128-2-cupertino.miranda@oracle.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin --- kernel/bpf/verifier.c | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index fe01edfcc34c6..7069e9f527eaa 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -15305,21 +15305,17 @@ static void __scalar64_min_max_lsh(struct bpf_reg_state *dst_reg, u64 umin_val, u64 umax_val) { /* Special case <<32 because it is a common compiler pattern to sign - * extend subreg by doing <<32 s>>32. In this case if 32bit bounds are - * positive we know this shift will also be positive so we can track - * bounds correctly. Otherwise we lose all sign bit information except - * what we can pick up from var_off. Perhaps we can generalize this - * later to shifts of any length. + * extend subreg by doing <<32 s>>32. smin/smax assignments are correct + * because s32 bounds don't flip sign when shifting to the left by + * 32bits. */ - if (umin_val == 32 && umax_val == 32 && dst_reg->s32_max_value >= 0) + if (umin_val == 32 && umax_val == 32) { dst_reg->smax_value = (s64)dst_reg->s32_max_value << 32; - else - dst_reg->smax_value = S64_MAX; - - if (umin_val == 32 && umax_val == 32 && dst_reg->s32_min_value >= 0) dst_reg->smin_value = (s64)dst_reg->s32_min_value << 32; - else + } else { + dst_reg->smax_value = S64_MAX; dst_reg->smin_value = S64_MIN; + } /* If we might shift our top bit out, then we know nothing */ if (dst_reg->umax_value > 1ULL << (63 - umax_val)) { -- 2.51.0 From - Sat Feb 28 17:57:39 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id oCMSNI4so2kvHzIAYBR5ng (envelope-from ) for ; Sat, 28 Feb 2026 17:57:34 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Sat, 28 Feb 2026 17:57:35 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vwOZK-0000000DueC-1Iyj for hi@josie.lol; Sat, 28 Feb 2026 17:57:34 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 4463631AAA81 for ; Sat, 28 Feb 2026 17:43:44 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F41F234EF18; Sat, 28 Feb 2026 17:34:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uBzKjERW" 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 D08194921A2; Sat, 28 Feb 2026 17:34:20 +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=1772300060; cv=none; b=B0DLVZOycdFw4cgcYPfsHfeAT5gu+cChFjzdKkt9jsdELz6G15Pj2zRMvvlOFpKuvzBfO1Rq5WqUh12ckSmEl5yUgMKY410lTE4VQUlltJds/ZhmtYiz5pwLIt6Uz5N+5VByMTBiNBKUYol56onLBRyl1aHBBchSk5yzuMmYagY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300060; c=relaxed/simple; bh=iPHL5fHDNkD0s+OK8W08RPRr3MyV1q3fjkFPa2mlYxo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uickTqyPr8LFXfz6fcAeDLzJgjIaC2EnUMV6wh9QIniugWfVYn/oK/7wDkrAuQ21JqvVPuOFRMeCYAiPa0843f1TIOBvtWR03q0tr318egsVfSTPRDv8OVJ7xyPOf8+dj6AIHwZecDF1zCNFPZXxI+G5Rx6gpV5O1//h9skXGtc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uBzKjERW; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED8A1C19423; Sat, 28 Feb 2026 17:34:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300060; bh=iPHL5fHDNkD0s+OK8W08RPRr3MyV1q3fjkFPa2mlYxo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uBzKjERWsBY3e9hhJUq6Sl5JU9scrdKdUyP7EjGixqgUcN3a7dJlA4sWSsIa5gwNh 7vcgBt9t06UaN1S+PNLZaZgsypAssoBjfNZ3JYHVxpx00oHKcoaDNQW1hBwcoCiV+j jgWpswmuom3U20IXj/p94DPFUeEKBIl5tfMNkl53GAfkZlKGF1Yd7prH0ok4XOdzfz Rjl/8zClSBIbnuEgE67e9HL9R5ziIjc8NOoYaVfwilKDyjuDYfQ0MvumPQbfst/Kq3 VUr048RR8uTWJf8sPT+zVal3Q8D48O5tbfhDwfJGJfgvF/4rheGEVH9lF1A25F0WJX gmt5d4iGlC2OA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Magnus Lindholm , Ivan Kokshaysky , Matoro Mahri , Michael Cree , Sasha Levin Subject: [PATCH 6.19 074/844] alpha: fix user-space corruption during memory compaction Date: Sat, 28 Feb 2026 12:19:47 -0500 Message-ID: <20260228173244.1509663-75-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://docs.mxroute.com/docs/expert-spam-filtering.html --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.105.105.114 listed in zen.spamhaus.org] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Magnus Lindholm [ Upstream commit dd5712f3379cfe760267cdd28ff957d9ab4e51c7 ] Alpha systems can suffer sporadic user-space crashes and heap corruption when memory compaction is enabled. Symptoms include SIGSEGV, glibc allocator failures (e.g. "unaligned tcache chunk"), and compiler internal errors. The failures disappear when compaction is disabled or when using global TLB invalidation. The root cause is insufficient TLB shootdown during page migration. Alpha relies on ASN-based MM context rollover for instruction cache coherency, but this alone is not sufficient to prevent stale data or instruction translations from surviving migration. Fix this by introducing a migration-specific helper that combines: - MM context invalidation (ASN rollover), - immediate per-CPU TLB invalidation (TBI), - synchronous cross-CPU shootdown when required. The helper is used only by migration/compaction paths to avoid changing global TLB semantics. Additionally, update flush_tlb_other(), pte_clear(), to use READ_ONCE()/WRITE_ONCE() for correct SMP memory ordering. This fixes observed crashes on both UP and SMP Alpha systems. Reviewed-by: Ivan Kokshaysky Tested-by: Matoro Mahri Tested-by: Michael Cree Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260102173603.18247-2-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin --- arch/alpha/include/asm/pgtable.h | 33 ++++++++- arch/alpha/include/asm/tlbflush.h | 4 +- arch/alpha/mm/Makefile | 2 +- arch/alpha/mm/tlbflush.c | 112 ++++++++++++++++++++++++++++++ 4 files changed, 148 insertions(+), 3 deletions(-) create mode 100644 arch/alpha/mm/tlbflush.c diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h index 90e7a95391022..c9508ec37efc4 100644 --- a/arch/alpha/include/asm/pgtable.h +++ b/arch/alpha/include/asm/pgtable.h @@ -17,6 +17,7 @@ #include /* For TASK_SIZE */ #include #include +#include struct mm_struct; struct vm_area_struct; @@ -183,6 +184,9 @@ extern inline void pud_set(pud_t * pudp, pmd_t * pmdp) { pud_val(*pudp) = _PAGE_TABLE | ((((unsigned long) pmdp) - PAGE_OFFSET) << (32-PAGE_SHIFT)); } +extern void migrate_flush_tlb_page(struct vm_area_struct *vma, + unsigned long addr); + extern inline unsigned long pmd_page_vaddr(pmd_t pmd) { @@ -202,7 +206,7 @@ extern inline int pte_none(pte_t pte) { return !pte_val(pte); } extern inline int pte_present(pte_t pte) { return pte_val(pte) & _PAGE_VALID; } extern inline void pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep) { - pte_val(*ptep) = 0; + WRITE_ONCE(pte_val(*ptep), 0); } extern inline int pmd_none(pmd_t pmd) { return !pmd_val(pmd); } @@ -264,6 +268,33 @@ extern inline pte_t * pte_offset_kernel(pmd_t * dir, unsigned long address) extern pgd_t swapper_pg_dir[1024]; +#ifdef CONFIG_COMPACTION +#define __HAVE_ARCH_PTEP_GET_AND_CLEAR + +static inline pte_t ptep_get_and_clear(struct mm_struct *mm, + unsigned long address, + pte_t *ptep) +{ + pte_t pte = READ_ONCE(*ptep); + + pte_clear(mm, address, ptep); + return pte; +} + +#define __HAVE_ARCH_PTEP_CLEAR_FLUSH + +static inline pte_t ptep_clear_flush(struct vm_area_struct *vma, + unsigned long addr, pte_t *ptep) +{ + struct mm_struct *mm = vma->vm_mm; + pte_t pte = ptep_get_and_clear(mm, addr, ptep); + + page_table_check_pte_clear(mm, pte); + migrate_flush_tlb_page(vma, addr); + return pte; +} + +#endif /* * The Alpha doesn't have any external MMU info: the kernel page * tables contain all the necessary information. diff --git a/arch/alpha/include/asm/tlbflush.h b/arch/alpha/include/asm/tlbflush.h index ba4b359d6c395..0c8529997f54e 100644 --- a/arch/alpha/include/asm/tlbflush.h +++ b/arch/alpha/include/asm/tlbflush.h @@ -58,7 +58,9 @@ flush_tlb_other(struct mm_struct *mm) unsigned long *mmc = &mm->context[smp_processor_id()]; /* Check it's not zero first to avoid cacheline ping pong when possible. */ - if (*mmc) *mmc = 0; + + if (READ_ONCE(*mmc)) + WRITE_ONCE(*mmc, 0); } #ifndef CONFIG_SMP diff --git a/arch/alpha/mm/Makefile b/arch/alpha/mm/Makefile index 101dbd06b4ceb..2d05664058f64 100644 --- a/arch/alpha/mm/Makefile +++ b/arch/alpha/mm/Makefile @@ -3,4 +3,4 @@ # Makefile for the linux alpha-specific parts of the memory manager. # -obj-y := init.o fault.o +obj-y := init.o fault.o tlbflush.o diff --git a/arch/alpha/mm/tlbflush.c b/arch/alpha/mm/tlbflush.c new file mode 100644 index 0000000000000..ccbc317b9a348 --- /dev/null +++ b/arch/alpha/mm/tlbflush.c @@ -0,0 +1,112 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Alpha TLB shootdown helpers + * + * Copyright (C) 2025 Magnus Lindholm + * + * Alpha-specific TLB flush helpers that cannot be expressed purely + * as inline functions. + * + * These helpers provide combined MM context handling (ASN rollover) + * and immediate TLB invalidation for page migration and memory + * compaction paths, where lazy shootdowns are insufficient. + */ + +#include +#include +#include +#include +#include +#include + +#define asn_locked() (cpu_data[smp_processor_id()].asn_lock) + +/* + * Migration/compaction helper: combine mm context (ASN) handling with an + * immediate per-page TLB invalidate and (for exec) an instruction barrier. + * + * This mirrors the SMP combined IPI handler semantics, but runs locally on UP. + */ +#ifndef CONFIG_SMP +void migrate_flush_tlb_page(struct vm_area_struct *vma, + unsigned long addr) +{ + struct mm_struct *mm = vma->vm_mm; + int tbi_type = (vma->vm_flags & VM_EXEC) ? 3 : 2; + + /* + * First do the mm-context side: + * If we're currently running this mm, reload a fresh context ASN. + * Otherwise, mark context invalid. + * + * On UP, this is mostly about matching the SMP semantics and ensuring + * exec/i-cache tagging assumptions hold when compaction migrates pages. + */ + if (mm == current->active_mm) + flush_tlb_current(mm); + else + flush_tlb_other(mm); + + /* + * Then do the immediate translation kill for this VA. + * For exec mappings, order instruction fetch after invalidation. + */ + tbi(tbi_type, addr); +} + +#else +struct tlb_mm_and_addr { + struct mm_struct *mm; + unsigned long addr; + int tbi_type; /* 2 = DTB, 3 = ITB+DTB */ +}; + +static void ipi_flush_mm_and_page(void *x) +{ + struct tlb_mm_and_addr *d = x; + + /* Part 1: mm context side (Alpha uses ASN/context as a key mechanism). */ + if (d->mm == current->active_mm && !asn_locked()) + __load_new_mm_context(d->mm); + else + flush_tlb_other(d->mm); + + /* Part 2: immediate per-VA invalidation on this CPU. */ + tbi(d->tbi_type, d->addr); +} + +void migrate_flush_tlb_page(struct vm_area_struct *vma, unsigned long addr) +{ + struct mm_struct *mm = vma->vm_mm; + struct tlb_mm_and_addr d = { + .mm = mm, + .addr = addr, + .tbi_type = (vma->vm_flags & VM_EXEC) ? 3 : 2, + }; + + /* + * One synchronous rendezvous: every CPU runs ipi_flush_mm_and_page(). + * This is the "combined" version of flush_tlb_mm + per-page invalidate. + */ + preempt_disable(); + on_each_cpu(ipi_flush_mm_and_page, &d, 1); + + /* + * mimic flush_tlb_mm()'s mm_users<=1 optimization. + */ + if (atomic_read(&mm->mm_users) <= 1) { + + int cpu, this_cpu; + this_cpu = smp_processor_id(); + + for (cpu = 0; cpu < NR_CPUS; cpu++) { + if (!cpu_online(cpu) || cpu == this_cpu) + continue; + if (READ_ONCE(mm->context[cpu])) + WRITE_ONCE(mm->context[cpu], 0); + } + } + preempt_enable(); +} + +#endif -- 2.51.0 From - Sat Feb 28 17:57:47 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 6DbUOZYso2k0HzIAYBR5ng (envelope-from ) for ; Sat, 28 Feb 2026 17:57:42 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Sat, 28 Feb 2026 17:57:43 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vwOZS-0000000DuuG-2576 for hi@josie.lol; Sat, 28 Feb 2026 17:57:42 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 44181314C62D for ; Sat, 28 Feb 2026 17:53:15 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C6A334D991D; Sat, 28 Feb 2026 17:35:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="q/Sza/uv" 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 A3B054D991A; Sat, 28 Feb 2026 17:35:14 +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=1772300114; cv=none; b=P6Ye18wzEXHiQ+Q4z7yz+UmsX65GAdPv5vs4dtwXBlwSuLTgQ6HP8a8vdpQC12fiGeR8zNpxvb5pqPDxYwCk1VTsPPXia5+owBsRVQQbOlO0Xf7dwTmTjAaVvKTT5lTDo8qYJ19wUX0gBBTSAInnq/9z+/eQq48zF2zNWN9yFDA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300114; c=relaxed/simple; bh=qM7gp6HDaVPEmQMATIfFXNVj9J3aUDIQ9zDTxA3dCqw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EkFXEFuX+kKV3NqLyyGkCk0xuJnbpHeSYIPMeBawzTyY2iQl9EuMDEi4QKMbzPYahZY62VNs5Owe44ghvc2wBe+w3kGwP3+xU8pURlmv260M2ugpb50DocNMdjQcoAyX4Uy0g7Vqqs7azVOAtHua8qECvUT9Oys0QORlvBG6afE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q/Sza/uv; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95891C19423; Sat, 28 Feb 2026 17:35:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300114; bh=qM7gp6HDaVPEmQMATIfFXNVj9J3aUDIQ9zDTxA3dCqw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q/Sza/uvloARo5emfZIRZyGlwJanSE6exJIceOGNgIlBggH10o8xQdmQVjdxQuo6l edN8Atcm8gmsWEHWmwgBMAj0N9GA2hWOcwC+UI1pxnIQWGcx2yME5C1A6l6WGsT05E kvymBOn+EimtMiMIu+OrLB7RJ2+wPO9XWAdqui627Jil672GJ+d9bYB3u3oC8i1N4E jI3g1RdFWsLT19MRzi8AAGgmGV/XwWo4yuwrDNmN2Y3XaX3u8sxdraNGwy3ZU8RaYM IrI094+1wweYqnsnC1xNpC+BXq9uuRwW9yEt2qhz21kD8yAfiaYeaFhOX5ilM6M4OT a2iW1KbCWkK1A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tao Zhou , Hawking Zhang , Alex Deucher , Sasha Levin Subject: [PATCH 6.19 131/844] drm/amdgpu: fix the calculation of RAS bad page number Date: Sat, 28 Feb 2026 12:20:44 -0500 Message-ID: <20260228173244.1509663-132-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://docs.mxroute.com/docs/expert-spam-filtering.html --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.234.253.10 listed in zen.spamhaus.org] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Tao Zhou [ Upstream commit f752e79d38857011f1293fcb6c810409c3b669ee ] __amdgpu_ras_restore_bad_pages is responsible for the maintenance of bad page number, drop the unnecessary bad page number update in the error handling path of add_bad_pages. Signed-off-by: Tao Zhou Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 8de9f68f7bea6..9c21401c9b830 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -3249,8 +3249,6 @@ int amdgpu_ras_add_bad_pages(struct amdgpu_device *adev, /* deal with retire_unit records a time */ ret = __amdgpu_ras_convert_rec_array_from_rom(adev, &bps[i], &err_data, nps); - if (ret) - con->bad_page_num -= adev->umc.retire_unit; i += (adev->umc.retire_unit - 1); } else { break; @@ -3263,8 +3261,6 @@ int amdgpu_ras_add_bad_pages(struct amdgpu_device *adev, for (; i < pages; i++) { ret = __amdgpu_ras_convert_rec_from_rom(adev, &bps[i], &err_data, nps); - if (ret) - con->bad_page_num -= adev->umc.retire_unit; } con->eh_data->count_saved = con->eh_data->count; -- 2.51.0 From - Sat Feb 28 17:57:59 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id ABjeBKMso2kqHzIAYBR5ng (envelope-from ) for ; Sat, 28 Feb 2026 17:57:55 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Sat, 28 Feb 2026 17:57:55 +0000 Received: from sin.lore.kernel.org ([104.64.211.4]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vwOZe-0000000DvJM-0TEb for hi@josie.lol; Sat, 28 Feb 2026 17:57:55 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with ESMTP id 6EDC13093D54 for ; Sat, 28 Feb 2026 17:41:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 151F248B37F; Sat, 28 Feb 2026 17:34:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lq53E0Aa" 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 E64B948B37D; Sat, 28 Feb 2026 17:34:10 +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=1772300051; cv=none; b=CeuIS5/nIywm4oTm7xXUQVaNu4/ooAp2kcvutxaxJob2/qYmHqno5iNGPmUmn3sK12dWRRVMpO02z/3VOjDA618tw6ZAK2j1UkiU/eQ9iOopaOl1bSNBONEbFFUjuAQwdA/AOagQZy3kWkykHF6gY6pHEwUZNgthjb7lFLJNEhA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300051; c=relaxed/simple; bh=SxsZQUx3dc03EUsZvghPb+/oSolQMLkg3M61Te1RedM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UNkNRYveivzaAq5zffFj3cHfkZ9eSYZIqAoxLBPw170S7EbXRbGOgBvaKEDZZ8azn8xRRy0oFOgR4fS//E2WGZ4OuFsWiO7FlisoQGPQM9st7IlZeRq3HYBtJCjGgbTxpf1DmYG49U7OZ22ApY+1uHRdBZ+K0A53FgIcBPqE5kw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lq53E0Aa; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51ADFC19423; Sat, 28 Feb 2026 17:34:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300050; bh=SxsZQUx3dc03EUsZvghPb+/oSolQMLkg3M61Te1RedM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lq53E0Aa3OVBFhTmFMVcY2SbHSdCUzfvl3b4LU0m6qOaLwMnh+GvxhAwF5LjQa2ve +PlRu8iR7B7LO2Q8tAoGnkYCd59uzucjxwCmTp2/3tDe3ZDRuS+BnGZXNSZfU4LcGO spXJ8lsr3tmfssPrtXZ3CNkK1s7dB59x9jN27pmz8uLpcP4MJbUPHlGrWEPMzrBfS1 /acu06Xvshdh0We0lYu7f1beDUhj3S9aDpxEqG8XWVLw84fM5x4e8U+HYL+PPu8ll7 DdIW0m/WdyAZq2dFfjPDX2wIqqxgo3zDdHpCuyWBvCFuRng1voPr3/S/xL9zsyk+aO mkkR3fakGht/g== From: Sasha Levin