From: Jiaqi Yan <jiaqiyan@google.com>
To: ankita@nvidia.com
Cc: aniketa@nvidia.com, vsethi@nvidia.com, jgg@nvidia.com,
mochs@nvidia.com, skolothumtho@nvidia.com, linmiaohe@huawei.com,
nao.horiguchi@gmail.com, akpm@linux-foundation.org,
david@redhat.com, lorenzo.stoakes@oracle.com,
Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, tony.luck@intel.com,
bp@alien8.de, rafael@kernel.org, guohanjun@huawei.com,
mchehab@kernel.org, lenb@kernel.org, kevin.tian@intel.com,
alex@shazbot.org, cjia@nvidia.com, kwankhede@nvidia.com,
targupta@nvidia.com, zhiw@nvidia.com, dnigam@nvidia.com,
kjaju@nvidia.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-edac@vger.kernel.org,
Jonathan.Cameron@huawei.com, ira.weiny@intel.com,
Smita.KoralahalliChannabasappa@amd.com,
u.kleine-koenig@baylibre.com, peterz@infradead.org,
linux-acpi@vger.kernel.org, kvm@vger.kernel.org,
Axel Rasmussen <axelrasmussen@google.com>
Subject: Re: [PATCH v5 0/3] mm: Implement ECC handling for pfn with no struct page
Date: Fri, 16 Jan 2026 17:46:27 -0800 [thread overview]
Message-ID: <CACw3F51k=sFtXB1JE3HCcXP6EA0Tt4Yf44VUi3JLz0bgW-aArQ@mail.gmail.com> (raw)
In-Reply-To: <20251102184434.2406-1-ankita@nvidia.com>
On Sun, Nov 2, 2025 at 10:45 AM <ankita@nvidia.com> wrote:
>
> From: Ankit Agrawal <ankita@nvidia.com>
>
> Poison (or ECC) errors can be very common on a large size cluster.
> The kernel MM currently handles ECC errors / poison only on memory page
> backed by struct page. The handling is currently missing for the PFNMAP
> memory that does not have struct pages. The series adds such support.
>
> Implement a new ECC handling for memory without struct pages. Kernel MM
> expose registration APIs to allow modules that are managing the device
> to register its device memory region. MM then tracks such regions using
> interval tree.
>
> The mechanism is largely similar to that of ECC on pfn with struct pages.
> If there is an ECC error on a pfn, all the mapping to it are identified
> and a SIGBUS is sent to the user space processes owning those mappings.
> Note that there is one primary difference versus the handling of the
> poison on struct pages, which is to skip unmapping to the faulty PFN.
> This is done to handle the huge PFNMAP support added recently [1] that
> enables VM_PFNMAP vmas to map at PMD or PUD level. A poison to a PFN
> mapped in such as way would need breaking the PMD/PUD mapping into PTEs
> that will get mirrored into the S2. This can greatly increase the cost
> of table walks and have a major performance impact.
>
> nvgrace-gpu-vfio-pci module maps the device memory to user VA (Qemu) using
> remap_pfn_range without being added to the kernel [2]. These device memory
> PFNs are not backed by struct page. So make nvgrace-gpu-vfio-pci module
> make use of the mechanism to get poison handling support on the device
> memory.
>
> Patch rebased to v6.17-rc7.
>
> Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
> ---
>
> Link: https://lore.kernel.org/all/20251026141919.2261-1-ankita@nvidia.com/ [v4]
>
> v4 -> v5
> - Removed pfn_space NULL checks. Instead a wrong parameter would cause
> a panic. (Thanks Andrew Morton for suggestion)
> - Log message to mention kmalloc allocation error and the failure to
> kill a process. (Thanks Andrew Morton)
> - Comments with 80 chars.
>
> v3 -> v4
> - Added guards in memory_failure_pfn, register, unregister function to
> simplify code. (Thanks Ira Weiny for suggestion).
> - Collected reviewed-by from Shuai Xue (Thanks!) on the mm GHES patch. Also
> moved it to the front of the series.
> - Added check for interval_tree_iter_first before removing the device
> memory region. (Thanks Jiaqi Yan for suggestion)
> - If pfn doesn't belong to any address space mapping, returning
> MF_IGNORED (Thanks Miaohe Lin for suggestion).
> - Updated patch commit to add more details on the perf impact on
> HUGE PFNMAP (Thanks Jason Gunthorpe, Tony Luck for suggestion).
>
> v2 -> v3
> - Rebased to v6.17-rc7.
> - Skipped the unmapping of PFNMAP during reception of poison. Suggested by
> Jason Gunthorpe, Jiaqi Yan, Vikram Sethi (Thanks!)
> - Updated the check to prevent multiple registration to the same PFN
> range using interval_tree_iter_first. Thanks Shameer Kolothum for the
> suggestion.
> - Removed the callback function in the nvgrace-gpu requiring tracking of
> poisoned PFN as it isn't required anymore.
Hi Ankit,
I get that for nvgrace-gpu driver, you removed pfn_address_space_ops
because there is no need to unmap poisoned HBM page.
What about the nvgrace-egm driver? Now that you removed the
pfn_address_space_ops callback from pfn_address_space in [1], how can
nvgrace-egm driver know the poisoned EGM pages at runtime?
I expect the functionality to return retired pages should also include
runtime poisoned pages, which are not in the list queried from
egm-retired-pages-data-base during initialization. Or maybe my
expection is wrong/obsolete?
[1] https://lore.kernel.org/linux-mm/20230920140210.12663-2-ankita@nvidia.com
[2] https://lore.kernel.org/kvm/20250904040828.319452-12-ankita@nvidia.com
> - Introduced seperate collect_procs_pfn function to collect the list of
> processes mapping to the poisoned PFN.
>
> v1 -> v2
> - Change poisoned page tracking from bitmap to hashtable.
> - Addressed miscellaneous comments in v1.
>
> Link: https://lore.kernel.org/all/20240826204353.2228736-1-peterx@redhat.com/ [1]
> Link: https://lore.kernel.org/all/20240220115055.23546-1-ankita@nvidia.com/ [2]
>
> Ankit Agrawal (3):
> mm: Change ghes code to allow poison of non-struct pfn
> mm: handle poisoning of pfn without struct pages
> vfio/nvgrace-gpu: register device memory for poison handling
>
> MAINTAINERS | 1 +
> drivers/acpi/apei/ghes.c | 6 --
> drivers/vfio/pci/nvgrace-gpu/main.c | 45 ++++++++-
> include/linux/memory-failure.h | 17 ++++
> include/linux/mm.h | 1 +
> include/ras/ras_event.h | 1 +
> mm/Kconfig | 1 +
> mm/memory-failure.c | 145 +++++++++++++++++++++++++++-
> 8 files changed, 209 insertions(+), 8 deletions(-)
> create mode 100644 include/linux/memory-failure.h
>
> --
> 2.34.1
>
>
next prev parent reply other threads:[~2026-01-17 1:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-02 18:44 ankita
2025-11-02 18:44 ` [PATCH v5 1/3] mm: Change ghes code to allow poison of non-struct pfn ankita
2025-11-02 18:44 ` [PATCH v5 2/3] mm: handle poisoning of pfn without struct pages ankita
2025-11-04 2:49 ` Andrew Morton
2025-11-02 18:44 ` [PATCH v5 3/3] vfio/nvgrace-gpu: register device memory for poison handling ankita
2025-11-06 21:56 ` Alex Williamson
2025-11-04 2:47 ` [PATCH v5 0/3] mm: Implement ECC handling for pfn with no struct page Andrew Morton
2025-11-04 17:15 ` Ankit Agrawal
2026-01-17 1:46 ` Jiaqi Yan [this message]
2026-01-17 5:36 ` Ankit Agrawal
2026-01-20 16:28 ` Jiaqi Yan
2026-01-21 5:51 ` Jiaqi Yan
2026-01-21 22:14 ` Ankit Agrawal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACw3F51k=sFtXB1JE3HCcXP6EA0Tt4Yf44VUi3JLz0bgW-aArQ@mail.gmail.com' \
--to=jiaqiyan@google.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Liam.Howlett@oracle.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=akpm@linux-foundation.org \
--cc=alex@shazbot.org \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=axelrasmussen@google.com \
--cc=bp@alien8.de \
--cc=cjia@nvidia.com \
--cc=david@redhat.com \
--cc=dnigam@nvidia.com \
--cc=guohanjun@huawei.com \
--cc=ira.weiny@intel.com \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kjaju@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=lenb@kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mchehab@kernel.org \
--cc=mhocko@suse.com \
--cc=mochs@nvidia.com \
--cc=nao.horiguchi@gmail.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rppt@kernel.org \
--cc=skolothumtho@nvidia.com \
--cc=surenb@google.com \
--cc=targupta@nvidia.com \
--cc=tony.luck@intel.com \
--cc=u.kleine-koenig@baylibre.com \
--cc=vbabka@suse.cz \
--cc=vsethi@nvidia.com \
--cc=zhiw@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox