From nobody Tue Jun 16 02:34:52 2026 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 7F8562C3255; Wed, 15 Apr 2026 12:55:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776257751; cv=none; b=EhKeengNIl6UC36uCr+PDGH6SS0Q5c9GV6KETvgo08yDBFm3jGtIO9Nn8naINURHfEes1PvjtMRNjLCx1spvFk7xVMxPYQhQLEViJWp+P2eZ6wG9e6TGjpvmZst6aNe1dvrwDlky2UcGYb1vmLCvoN/Pr/YaGdTFMLNcor01sag= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776257751; c=relaxed/simple; bh=gqQVMT9Twy239JXZaAdY+DqLzM5N7ASaSKNxyeQsFwM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=lTEorXaXZSndB0oEj90WLnN8GWB51F5Uztq5dsIWSx/epF/522MCgd5/ZisRh0GS8uoOvwtHJtUTHnwE+TxV0X3Qu47yXsAa22geEbJ4yxFf1AP2XM0AVjq5uddwEKq69Oh3B1k/n+soyNQKa7KW3gl8uCHAyyoYti7Twei9JIk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=none smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=IFJ+GOGS; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="IFJ+GOGS" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Cc:To:In-Reply-To:References: Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date: From:Reply-To:Content-ID:Content-Description; bh=2DOYW7+fbeL2VNYTSascVM/JMexV13XGSf3P0Srb5Ds=; b=IFJ+GOGS0YQUYc6mik52wA1cDD MFWB463UWmaMPNuGOyI5IdsLAdUyBFiCLDQCZASKw3tPfwYScMXeqQAQz13uDHKbgwvwTfRRwFfEH +Fg7Ls0UDOaH0lwEYehEtvGKp/PtN2YY88ezIsrVVNDCR5gBiOgva7pXQzkpajNCvz+6gN+iHXh+y M9dFguDy1xu3052goKY6mEjGVfn5NWXj77n4kOQBInXRo31aK4goaN1yoC8xGHHQIjY/4fD885eU9 bnDgqpcXP8Ty+BPYa0/CCTah9+LbpbNtup3JfVma6pkNxUalMwDhC4dgxg3c/Gr+d3e0mbX6Ep5g2 Qfx6T/6A==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wCzmT-00Dqoz-0H; Wed, 15 Apr 2026 12:55:45 +0000 From: Breno Leitao Date: Wed, 15 Apr 2026 05:55:00 -0700 Subject: [PATCH v4 1/3] mm/memory-failure: report MF_MSG_KERNEL for reserved pages Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260415-ecc_panic-v4-1-2d0277f8f601@debian.org> References: <20260415-ecc_panic-v4-0-2d0277f8f601@debian.org> In-Reply-To: <20260415-ecc_panic-v4-0-2d0277f8f601@debian.org> To: Miaohe Lin , Naoya Horiguchi , Andrew Morton , Jonathan Corbet , Shuah Khan , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Breno Leitao , kernel-team@meta.com X-Mailer: b4 0.16-dev-453a6 X-Developer-Signature: v=1; a=openpgp-sha256; l=1134; i=leitao@debian.org; h=from:subject:message-id; bh=gqQVMT9Twy239JXZaAdY+DqLzM5N7ASaSKNxyeQsFwM=; b=owEBbQKS/ZANAwAIATWjk5/8eHdtAcsmYgBp34rHDcA5eHUSdXrkgeIaYk41TbbLb9TXl+BjY 6x77pV5theJAjMEAAEIAB0WIQSshTmm6PRnAspKQ5s1o5Of/Hh3bQUCad+KxwAKCRA1o5Of/Hh3 bQIKEACD+IGdXtgFH+lisYO7YsRhhqel9PluKZzzcoUfGdc6P14H+TFb2464+DI2oIPNAwvgEwX jH9rCYctvOXLOw+xWMLkV93suYqaue4pinawsq7dlXzc1HakW3UH76VhN5H5MH7MfO9H4hRCjgg HNyZJ1mpxffHuF8X+Jfd4JKSAXYrBJBAvIWfJviY1wCvEF+h68XRH2HI2RHkv2yNCnXAMlsjRBT 31tfanmOy4aoiTryVFnKyT25hYzyV1Xo5nxLUX9r/Xb/ZiDwLzAEGmS/+TDGM9Yea8F5+yBBU9S RS6s+AwbWWz4v+ivEIdpdTcvPkMQQJZEVkV3y0xXCOONj/AipjpNtZV9VBG+PbsbD0dJMPCZnUv 67DIBtdwz578QF3Y8rDlYvHLEumQdONxvgbtoW6ojj14MQewkKXoFA7lD38Yvr+VcSITd66WpxD BmBCO/CEaoEjuYM17Q8xHmaUFBKAasx3iLhZcUrJVWVk1fFAJHmhdwHSpIsXeZeR1BDw65iZBkG yFrHFacYkad0q04Vr0wjHxNvsEnLiSYvCGjKnF87lixM2iiTa3jNbPTv7dtEQtw9YmVLqgYSJ1W fDcxEAwGxw/ghBrItBe4N7Ug9I45U0k1DQ7jI05E75/BX5AtDMvl9seHv7zlU0Ez5Yz6Da991zw 52c86c15KsiVUHw== X-Developer-Key: i=leitao@debian.org; a=openpgp; fpr=AC8539A6E8F46702CA4A439B35A3939FFC78776D X-Debian-User: leitao When get_hwpoison_page() returns a negative value, distinguish reserved pages from other failure cases by reporting MF_MSG_KERNEL instead of MF_MSG_GET_HWPOISON. Reserved pages belong to the kernel and should be classified accordingly for proper handling. Signed-off-by: Breno Leitao Acked-by: Miaohe Lin --- mm/memory-failure.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index ee42d43613097..7b67e43dafbd1 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -2432,7 +2432,16 @@ int memory_failure(unsigned long pfn, int flags) } goto unlock_mutex; } else if (res < 0) { - res =3D action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED); + /* + * PageReserved is stable here: reserved pages have + * PG_reserved set at boot or by drivers and are never + * freed through the page allocator. + */ + if (PageReserved(p)) + res =3D action_result(pfn, MF_MSG_KERNEL, MF_IGNORED); + else + res =3D action_result(pfn, MF_MSG_GET_HWPOISON, + MF_IGNORED); goto unlock_mutex; } =20 --=20 2.52.0 From nobody Tue Jun 16 02:34:52 2026 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 6BF811DE894; Wed, 15 Apr 2026 12:55:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776257755; cv=none; b=V5WowTCxKoBQWNn1FfdRcIFG5SUrETKH5PXVPVLl5Hb2+cLvtRl6MtfbxcncNnj/11iBpq/O6h5/uF2oYlfYpEEpk5Eqwd/Zg3K8MqkfXGNRu8u0xYkXCK7t1CgTSNygLYLdlo0OgwyLc3nQ4p8caEKIN7Zw3u5ZKpr7NbGGH48= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776257755; c=relaxed/simple; bh=IKxZY+QCBI1vssaB8Z4zLZVgxsls9tCS4vJ5EhuGOy8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=n6L3A/62GNDVdeGg4XqZBMOStZDHfraQ6vd2NlDpW/bEZfQngQ7dXUEEgN9MxbgBjQZke3lzmoVWX6CFDQTVoUwnKG9eKm7mqIRVtD10FAErMSZJLA3sBKi0GC08jpl/Amxg0yxBL67QNC2D43yoJzgT9tIKa3HP5+onsX8+zio= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=none smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=ZKuk2y4e; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="ZKuk2y4e" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Cc:To:In-Reply-To:References: Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date: From:Reply-To:Content-ID:Content-Description; bh=81PtAqf4EEJbz8tHNP/52MeVt8twHrcmo+JkGArzbSs=; b=ZKuk2y4efzxsb/lHX6Zcesie92 ydtLVlZHMelFevN+NiBL91t4uWIwkxUJbFEl+nk45EcNWOojnmBqypiqXVgKAFyuHSZRxISrxSzwz xttF4FPHLTrWoD593KekIA78Jqu/BIoLvV8kSOPTyCiNgZFvEzEVLpNmf9O/CPyiD0++QiIur9HjU eAdUEW3XECc5pW5p8RUIpBHbWtNNxWM1N+vTLcCFGLhXxV7FgNkJYri3UU+syFdM0lzXHCaf7yvJE VghBMGliM+cpUhPRnZ1bi/gtpOiyPqTrCZ8dId+NOzO3C8UhYhFohMlFb3yK6WOj2i64LHg729bdM QGx6rFAA==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wCzmX-00Dqp4-2l; Wed, 15 Apr 2026 12:55:50 +0000 From: Breno Leitao Date: Wed, 15 Apr 2026 05:55:01 -0700 Subject: [PATCH v4 2/3] mm/memory-failure: add panic option for unrecoverable pages Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260415-ecc_panic-v4-2-2d0277f8f601@debian.org> References: <20260415-ecc_panic-v4-0-2d0277f8f601@debian.org> In-Reply-To: <20260415-ecc_panic-v4-0-2d0277f8f601@debian.org> To: Miaohe Lin , Naoya Horiguchi , Andrew Morton , Jonathan Corbet , Shuah Khan , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Breno Leitao , kernel-team@meta.com X-Mailer: b4 0.16-dev-453a6 X-Developer-Signature: v=1; a=openpgp-sha256; l=6778; i=leitao@debian.org; h=from:subject:message-id; bh=IKxZY+QCBI1vssaB8Z4zLZVgxsls9tCS4vJ5EhuGOy8=; b=owEBbQKS/ZANAwAIATWjk5/8eHdtAcsmYgBp34rHH7UCpnidfUCEs2zkTLG1E2h07NZhpz0Zi 25WmTkVjO+JAjMEAAEIAB0WIQSshTmm6PRnAspKQ5s1o5Of/Hh3bQUCad+KxwAKCRA1o5Of/Hh3 bWT3D/9jw9NwgA9KE/D8EiduG6QhX1Hs1DLTPLwaHjYM0qy8X5cwuGe9ZgfbeIl0+iMHubfnquQ 2w/9O+5Oug9I9yNGdzIVCbnWfuCNLYABfSUHYToeL3/54ZzMB2u5aGA54c5lq9KYl4O0pYSptDD JD4Ep0uKeSwxiNZVgxZyPMa2nSio9PS8Ov4ajeJ5ASFxjhMndbxHVdNPZSwrn4ktb9+4Z7ZiP+2 6ks/vXWy+slzptymRHjfCjjEuwxE4hhlwi0SbpA52GWJ+enwpov11zma0liEiYa9EkfhffJV7d8 yts2HX30+m6oWgVAEku309czHPftjgQ6JGktm8vo0Eqjh8xRbAP4UBKpKovmu7ZBcWFa93tvAgO 6i+kP99wxSueZn+9yvG6MNHTaDIyYkWksJ9lJGA0DkAN1/mVA2FH2Zw0z4hsxtNtN8D2tM/Fv6G pFt9K6g8Zn5l5TrdQhDIUmk+swl9vkuU7Ws5ahxG1pPE5z21wOaO/m43vn8BPc/Kfr7xWk7LZaX DN9AgbqJquqJcbHj88wnDpE1iqaeW3GqUuIATBEYebj9sxbG/bxoIfJYCuXDKMXAWMh6BBph81z BtAMc8YPsQU4NeiI5lbDVa5zeWo2n7mQ87Bcfr8z3hTYQ8mM573PQEk7knBpYbxwBebBOjfOo23 SC/ibS11Q+g+tqA== X-Developer-Key: i=leitao@debian.org; a=openpgp; fpr=AC8539A6E8F46702CA4A439B35A3939FFC78776D X-Debian-User: leitao Add a sysctl panic_on_unrecoverable_memory_failure that triggers a kernel panic when memory_failure() encounters pages that cannot be recovered. This provides a clean crash with useful debug information rather than allowing silent data corruption. The panic is triggered for three categories of unrecoverable failures, all requiring result =3D=3D MF_IGNORED: - MF_MSG_KERNEL: reserved pages identified via PageReserved. - MF_MSG_KERNEL_HIGH_ORDER: pages with refcount 0 that are not in the buddy allocator (e.g., tail pages of high-order kernel allocations). A TOCTOU race between get_hwpoison_page() and is_free_buddy_page() is possible when CONFIG_DEBUG_VM is disabled, since check_new_pages() is gated by is_check_pages_enabled() and becomes a no-op. Panicking is still correct: the physical memory has a hardware error regardless of who allocated the page. - MF_MSG_UNKNOWN: pages that do not match any known recoverable state in error_states[]. A theoretical false positive from concurrent LRU isolation is mitigated by identify_page_state()'s two-pass design which rechecks using saved page_flags. MF_MSG_GET_HWPOISON is intentionally excluded: it covers both non-reserved kernel memory (SLAB/SLUB, vmalloc, kernel stacks, page tables) and transient refcount races, so panicking would risk false positives. Signed-off-by: Breno Leitao --- mm/memory-failure.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++= ++++ 1 file changed, 81 insertions(+) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 7b67e43dafbd1..311344f332449 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -74,6 +74,8 @@ static int sysctl_memory_failure_recovery __read_mostly = =3D 1; =20 static int sysctl_enable_soft_offline __read_mostly =3D 1; =20 +static int sysctl_panic_on_unrecoverable_mf __read_mostly; + atomic_long_t num_poisoned_pages __read_mostly =3D ATOMIC_LONG_INIT(0); =20 static bool hw_memory_failure __read_mostly =3D false; @@ -155,6 +157,15 @@ static const struct ctl_table memory_failure_table[] = =3D { .proc_handler =3D proc_dointvec_minmax, .extra1 =3D SYSCTL_ZERO, .extra2 =3D SYSCTL_ONE, + }, + { + .procname =3D "panic_on_unrecoverable_memory_failure", + .data =3D &sysctl_panic_on_unrecoverable_mf, + .maxlen =3D sizeof(sysctl_panic_on_unrecoverable_mf), + .mode =3D 0644, + .proc_handler =3D proc_dointvec_minmax, + .extra1 =3D SYSCTL_ZERO, + .extra2 =3D SYSCTL_ONE, } }; =20 @@ -1281,6 +1292,59 @@ static void update_per_node_mf_stats(unsigned long p= fn, ++mf_stats->total; } =20 +/* + * Determine whether to panic on an unrecoverable memory failure. + * + * Design rationale: This design opts for immediate panic on kernel memory + * failures, capturing clean crashes rather than random crashes on MF_IGNO= RED + * pages. + * + * This panics on three categories of failures (all requiring result =3D= =3D + * MF_IGNORED, meaning the page was not recovered): + * + * - MF_MSG_KERNEL: Reserved pages (identified via PageReserved) that belo= ng + * to the kernel and cannot be recovered. + * + * - MF_MSG_KERNEL_HIGH_ORDER: Pages that get_hwpoison_page() observed as = free + * (refcount 0) but are not in the buddy allocator. These are kernel pag= es + * in a transient state between allocation and freeing. A TOCTOU race + * (page allocated between get_hwpoison_page() and is_free_buddy_page()) + * is possible when CONFIG_DEBUG_VM is disabled, since check_new_pages() + * is gated by is_check_pages_enabled() and becomes a no-op. However, + * panicking is still correct in this case: the physical memory has a + * hardware error, so an allocated hwpoisoned page is unrecoverable. + * + * - MF_MSG_UNKNOWN: Pages that reached identify_page_state() but did not + * match any known recoverable state in error_states[]. This is the + * catch-all for pages whose flags do not indicate a recoverable user or + * cache page (no LRU, no swapcache, no mlock, etc). A theoretical false + * positive exists if concurrent LRU isolation clears PG_lru between + * folio_lock() and saving page_flags, but this window is very narrow and + * mitigated by identify_page_state()'s two-pass design which rechecks + * using saved page_flags. + * + * Pages intentionally NOT included: + * - MF_MSG_GET_HWPOISON: get_hwpoison_page() failure on non-reserved page= s. + * This includes dynamically allocated kernel memory (SLAB/SLUB, vmalloc, + * kernel stacks, page tables) which are not PageReserved and fail + * get_hwpoison_page() with -EBUSY/-EIO. These share the return path with + * transient refcount races, so panicking here would risk false positive= s. + * + * Note: Some transient races in the buddy allocator path are mitigated by + * memory_failure()'s retry mechanism. When take_page_off_buddy() fails, + * the code clears PageHWPoison and retries the entire memory_failure() + * flow, allowing pages to be properly reclassified with updated flags. + */ +static bool panic_on_unrecoverable_mf(enum mf_action_page_type type, + enum mf_result result) +{ + return sysctl_panic_on_unrecoverable_mf && + result =3D=3D MF_IGNORED && + (type =3D=3D MF_MSG_KERNEL || + type =3D=3D MF_MSG_KERNEL_HIGH_ORDER || + type =3D=3D MF_MSG_UNKNOWN); +} + /* * "Dirty/Clean" indication is not 100% accurate due to the possibility of * setting PG_dirty outside page lock. See also comment above set_page_dir= ty(). @@ -1298,6 +1362,9 @@ static int action_result(unsigned long pfn, enum mf_a= ction_page_type type, pr_err("%#lx: recovery action for %s: %s\n", pfn, action_page_types[type], action_name[result]); =20 + if (panic_on_unrecoverable_mf(type, result)) + panic("Memory failure: %#lx: unrecoverable page", pfn); + return (result =3D=3D MF_RECOVERED || result =3D=3D MF_DELAYED) ? 0 : -EB= USY; } =20 @@ -2428,6 +2495,20 @@ int memory_failure(unsigned long pfn, int flags) } res =3D action_result(pfn, MF_MSG_BUDDY, res); } else { + /* + * The page has refcount 0 but is not in the buddy + * allocator =E2=80=94 it is a non-compound high-order kernel + * page (e.g., a tail page of a high-order allocation). + * + * A TOCTOU race where the page transitions from + * free-buddy to allocated between get_hwpoison_page() + * and is_free_buddy_page() is possible when + * CONFIG_DEBUG_VM is disabled (check_new_pages() is + * gated by is_check_pages_enabled() and becomes a + * no-op). Panicking is still correct: the physical + * memory has a hardware error regardless of who + * allocated the page. + */ res =3D action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED); } goto unlock_mutex; --=20 2.52.0 From nobody Tue Jun 16 02:34:52 2026 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 D86523264F2; Wed, 15 Apr 2026 12:55:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776257761; cv=none; b=ITRN//cTjfRFUc9ypfun6zs2X+GdOEg6Ico4ZOPz05n8h1+AyFGQT/3bRF/77PidtkQzRjtLDhL8GUi7nmFpS9urmsCnYatuwuXVfxY4gonXmSg/Oap0428bVslag00uY3pEXnq99yDpmjXEtc7CfpUUWOUr45ERlBK/heKCqDk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776257761; c=relaxed/simple; bh=EXsbl4LOvo0JX/uD060vsfFhdmmxwiFz5i7QxlbIQHA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=h+F3AqmQjh8mWi6TIzhxcxk/tR9I3P0+lC7+XF46ndkQiBXuNvFRAm9OviHVehJ5Qd44dclNk4uyr/NjY5ETEX6H7hNUQkV4ZWXuoDX4a4xPAhZujOJ9lGOyfPf53NC1E2rigcZEVnofGQTwHTrWyZ/eY6OAJo46zpWxrYzMis0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=none smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=ASpGYU5v; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="ASpGYU5v" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Cc:To:In-Reply-To:References: Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date: From:Reply-To:Content-ID:Content-Description; bh=riFflWboHrZlyZ/i6D5M814hAUkl2Z5dRR5vqmlgkzI=; b=ASpGYU5vczZTHN/XsxD/FLQAyQ 6SzORlkS8+LQdWaLAGjWoTcV7U7EYjKzXHAq7//tS6tYSTXZtc/JKbx6UDiELBiTw8J/KuM5tLOOB X0flixUOnVJlzq8BhnGjqvFK1p4HqRaWOQmjtn/WSv60pvdqlVuHYewUqjczEUZ3VtuTE3IClQkUJ 3vK2CYHy6gkAoYfCq26Z7rO4tpe+64ickRryFncWPb45uk6KSDcTx+VrN0CDecnJIOdTFafFVcbjM b0WQf668NkUFjkp/OgnC7+koOfWTN+K1mDC1pA316ZO+R+XfvyaShK/gHr96w7sJ/1usqlmgZz5De WmC/jvgw==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wCzmc-00DqpN-1v; Wed, 15 Apr 2026 12:55:54 +0000 From: Breno Leitao Date: Wed, 15 Apr 2026 05:55:02 -0700 Subject: [PATCH v4 3/3] Documentation: document panic_on_unrecoverable_memory_failure sysctl Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260415-ecc_panic-v4-3-2d0277f8f601@debian.org> References: <20260415-ecc_panic-v4-0-2d0277f8f601@debian.org> In-Reply-To: <20260415-ecc_panic-v4-0-2d0277f8f601@debian.org> To: Miaohe Lin , Naoya Horiguchi , Andrew Morton , Jonathan Corbet , Shuah Khan , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Breno Leitao , kernel-team@meta.com X-Mailer: b4 0.16-dev-453a6 X-Developer-Signature: v=1; a=openpgp-sha256; l=2686; i=leitao@debian.org; h=from:subject:message-id; bh=EXsbl4LOvo0JX/uD060vsfFhdmmxwiFz5i7QxlbIQHA=; b=owEBbQKS/ZANAwAIATWjk5/8eHdtAcsmYgBp34rHzbvgLtr3TTAmdP5mLG1e79OdmgxxC1fR1 +wKbsrHi8GJAjMEAAEIAB0WIQSshTmm6PRnAspKQ5s1o5Of/Hh3bQUCad+KxwAKCRA1o5Of/Hh3 bQ3gEACX1lxfvKvTxghRqJBwM6TajM+mlcfN8zoA9KsIMsIKnBuPbfHEWv1T8GFlR5n8AymDJBe x0r3lgTeAsJPVMBrRcFNRhonefmub4FF5hk5wbBOC+Q+7yAIumTYPAE5+l6lqJksMYHikqo6VDW 2KvRnkyZMRFcIMgvbGX5KW2LOUI1kZKDhPW/2/LJf30R2P/tLBuAhhDgNU7ZG0qFdrSUZ6qX5Qm MZtUxf6SwvbyI7JlJXcJI1xnyvvedDMlnDdx8J/18XW41zgn+cwIyEkpsuGXKkGsM1l2MoV8Wda NLByRpDUNOLjJVjcOCr3+OhplbQi3mR4Ph1qBjlWUY81StlgklIkJ/gsX39nSWWwuhAs0nXr3a1 wmY+10z+S/bTxsrSCBgLoOZ6vHptxax4m5lVZq+m1sO3Ked87jFkI2ke9mKKglZj/uZoMEJ7bKn RTXRZRH/BpW3tekyeeExVphRlRqExfEDJf6ueFYoDlShqS337Ozom6VffC2JB0CIdmlmDKO2uCy JNgSA4rGDzUtYBGuJFMPJpkS1fWgYjOJCvcVrRSqbfBEk/HQuo0Y0fz1motiv6ZpOFnavArDR14 B2tCROnjtxyr3R/NIPgC5E28Xe1Zleqo81haT8UE8WgWbEGcrzBcW0OluJ6W05YD9OGLw3VHRUe ayxkxb2pnDUn9hA== X-Developer-Key: i=leitao@debian.org; a=openpgp; fpr=AC8539A6E8F46702CA4A439B35A3939FFC78776D X-Debian-User: leitao Add documentation for the new vm.panic_on_unrecoverable_memory_failure sysctl, describing the three categories of failures that trigger a panic and noting which kernel page types are not yet covered. Signed-off-by: Breno Leitao --- Documentation/admin-guide/sysctl/vm.rst | 37 +++++++++++++++++++++++++++++= ++++ 1 file changed, 37 insertions(+) diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-= guide/sysctl/vm.rst index 97e12359775c9..592ce9ec38c4b 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -67,6 +67,7 @@ Currently, these files are in /proc/sys/vm: - page-cluster - page_lock_unfairness - panic_on_oom +- panic_on_unrecoverable_memory_failure - percpu_pagelist_high_fraction - stat_interval - stat_refresh @@ -925,6 +926,42 @@ panic_on_oom=3D2+kdump gives you very strong tool to i= nvestigate why oom happens. You can get snapshot. =20 =20 +panic_on_unrecoverable_memory_failure +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +When a hardware memory error (e.g. multi-bit ECC) hits a kernel page +that cannot be recovered by the memory failure handler, the default +behaviour is to ignore the error and continue operation. This is +dangerous because the corrupted data remains accessible to the kernel, +risking silent data corruption or a delayed crash when the poisoned +memory is next accessed. + +When enabled, this sysctl triggers a panic on three categories of +unrecoverable failures: reserved kernel pages, non-buddy kernel pages +with zero refcount (e.g. tail pages of high-order allocations), and +pages whose state cannot be classified as recoverable. + +Note that some kernel page types =E2=80=94 such as slab objects, vmalloc +allocations, kernel stacks, and page tables =E2=80=94 share a failure path +with transient refcount races and are not currently covered by this +option. I.e, do not panic when not confident of the page status. + +For many environments it is preferable to panic immediately with a clean +crash dump that captures the original error context, rather than to +continue and face a random crash later whose cause is difficult to +diagnose. + +=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +0 Try to continue operation (default). +1 Panic immediately. If the ``panic`` sysctl is also non-zero then the + machine will be rebooted. +=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Example:: + + echo 1 > /proc/sys/vm/panic_on_unrecoverable_memory_failure + + percpu_pagelist_high_fraction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =20 --=20 2.52.0