linux-kernel - [RFC PATCH v1 3/3] Documentation: add userspace MF recovery policy via memfd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250118231549.1652825-4-jiaqiyan@google.com>
Date: Sat, 18 Jan 2025 23:15:49 +0000
From: Jiaqi Yan <jiaqiyan@...gle.com>
To: nao.horiguchi@...il.com, linmiaohe@...wei.com
Cc: tony.luck@...el.com, wangkefeng.wang@...wei.com, willy@...radead.org, 
	jane.chu@...cle.com, akpm@...ux-foundation.org, osalvador@...e.de, 
	rientjes@...gle.com, duenwen@...gle.com, jthoughton@...gle.com, 
	jgg@...dia.com, ankita@...dia.com, peterx@...hat.com, 
	sidhartha.kumar@...cle.com, david@...hat.com, dave.hansen@...ux.intel.com, 
	muchun.song@...ux.dev, linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, Jiaqi Yan <jiaqiyan@...gle.com>
Subject: [RFC PATCH v1 3/3] Documentation: add userspace MF recovery policy
 via memfd

Document its motivation and userspace API.

Signed-off-by: Jiaqi Yan <jiaqiyan@...gle.com>
---
 Documentation/userspace-api/index.rst         |  1 +
 .../userspace-api/mfd_mfr_policy.rst          | 55 +++++++++++++++++++
 2 files changed, 56 insertions(+)
 create mode 100644 Documentation/userspace-api/mfd_mfr_policy.rst

diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst
index 274cc7546efc2..0f9783b8807ea 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -63,6 +63,7 @@ Everything else
    vduse
    futex2
    perf_ring_buffer
+   mfd_mfr_policy
 
 .. only::  subproject and html
 
diff --git a/Documentation/userspace-api/mfd_mfr_policy.rst b/Documentation/userspace-api/mfd_mfr_policy.rst
new file mode 100644
index 0000000000000..d4557693c2c40
--- /dev/null
+++ b/Documentation/userspace-api/mfd_mfr_policy.rst
@@ -0,0 +1,55 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==================================================
+Userspace Memory Failure Recovery Policy via memfd
+==================================================
+
+:Author:
+    Jiaqi Yan <jiaqiyan@...gle.com>
+
+
+Motivation
+==========
+
+When a userspace process is able to recover from memory failures (MF)
+caused by uncorrected memory error (UE) in the DIMM, especially when it is
+able to avoid consuming known UEs, keeping the memory page mapped and
+accessible may be benifical to the owning process for a couple of reasons:
+- The memory pages affected by UE have a large smallest granularity, for
+  example 1G hugepage, but the actual corrupted amount of the page is only
+  several cachlines. Losing the entire hugepage of data is unacceptable to
+  the application.
+- In addition to keeping the data accessible, the application still wants
+  to access with as large page size for the fastest virtual-to-physical
+  translations.
+
+Memory failure recovery for 1G or larger HugeTLB is a good example. With
+memfd userspace process can control whether the kernel hard offlines its
+memory (huge)pages that backs the in-RAM file created by memfd.
+
+
+User API
+========
+
+``int memfd_create(const char *name, unsigned int flags)``
+
+``MFD_MF_KEEP_UE_MAPPED``
+	When ``MFD_MF_KEEP_UE_MAPPED`` bit is set in ``flags``, MF recovery
+	in the kernel does not hard offline memory due to UE until the
+	returned ``memfd`` is released. IOW, the HWPoison-ed memory emains
+	accessible via the returned ``memfd`` or the memory mapping created
+	with the returned ``memfd``. Note the affected memory will be
+	immediately protected and isolated from future use (by both kernel
+	and userspace) once the owning process is gone. By default
+	``MFD_MF_KEEP_UE_MAPPED`` is not set, and kernel hard offlines
+	memory having UEs.
+
+Notes about the behavior and limitations
+- Even if the page affected by UE is kept, a portion of the (huge)page is
+  already lost due to hardware corruption, and the size of the portion
+  is the smallest page size that kernel uses to manages memory on the
+  architecture, i.e. PAGESIZE. Accessing a virtual address within any of
+  these parts results in a SIGBUS; accessing virtual address outside these
+  parts are good until it is corrupted by new memory error.
+- ``MFD_MF_KEEP_UE_MAPPED`` currently only works for HugeTLB, so
+  ``MFD_HUGETLB`` must also be set when setting ``MFD_MF_KEEP_UE_MAPPED``.
-- 
2.48.0.rc2.279.g1de40edade-goog