[PATCH v1 0/3] mm: fixup pfnmap memory failure handling

ankita@nvidia.com posted 3 patches 5 days, 1 hour ago
There is a newer version of this series
drivers/vfio/pci/nvgrace-gpu/main.c | 116 +++++++++++++++++++++++++++-
include/linux/memory-failure.h      |  15 +++-
mm/memory-failure.c                 |  29 ++++---
3 files changed, 143 insertions(+), 17 deletions(-)
[PATCH v1 0/3] mm: fixup pfnmap memory failure handling
Posted by ankita@nvidia.com 5 days, 1 hour ago
From: Ankit Agrawal <ankita@nvidia.com>

It was noticed during 6.19 merge window that the patch series [1] to
introduce memory failure handling for the PFNMAP memory is broken.

The expected behaviour of the series is to allow a driver (such as
nvgrace-gpu) to register its device memory with the mm. The mm would
then handle the poison on that registered memory region.

However, the following issues were identified in the patch series.
1. Faulty use of PFN instead of mapping file page offset to derive
the usermode process VA corresponding to the mapping to PFN.
2. nvgrace-gpu code called the registration at mmap, exposing it
to corruption. This may happen, when multiple mmap were called on the
same BAR. This issue was also noticed by Linus Torvalds who reverted
the patch [2].

This patch series addresses those issues.

Patch 1/3 fixes the first issue by translating PFN to page offset
and using that information to send the SIGBUS to the mapping process.
Patch 2/3 add stubs for CONFIG_MEMORY_FAILURE disabled.
Patch 3/3 is a resend of the reverted change to register the device
memory at the time of open instead of mmap.

Many thanks to Jason Gunthorpe (jgg@nvidia.com) and Alex Williamson
(alex@shazbot.org) for identifying the issue and suggesting the fix.

Link: https://lore.kernel.org/all/20251102184434.2406-1-ankita@nvidia.com/ [1]
Link: https://lore.kernel.org/all/20251102184434.2406-4-ankita@nvidia.com/ [2]

Ankit Agrawal (3):
  mm: fixup pfnmap memory failure handling to use pgoff
  mm: add stubs for PFNMAP memory failure registration functions
  vfio/nvgrace-gpu: register device memory for poison handling

 drivers/vfio/pci/nvgrace-gpu/main.c | 116 +++++++++++++++++++++++++++-
 include/linux/memory-failure.h      |  15 +++-
 mm/memory-failure.c                 |  29 ++++---
 3 files changed, 143 insertions(+), 17 deletions(-)

-- 
2.34.1
Re: [PATCH v1 0/3] mm: fixup pfnmap memory failure handling
Posted by Andrew Morton 4 days, 12 hours ago
On Thu, 11 Dec 2025 07:06:00 +0000 <ankita@nvidia.com> wrote:

> It was noticed during 6.19 merge window that the patch series [1] to
> introduce memory failure handling for the PFNMAP memory is broken.
> 
> The expected behaviour of the series is to allow a driver (such as
> nvgrace-gpu) to register its device memory with the mm. The mm would
> then handle the poison on that registered memory region.
> 
> However, the following issues were identified in the patch series.
> 1. Faulty use of PFN instead of mapping file page offset to derive
> the usermode process VA corresponding to the mapping to PFN.
> 2. nvgrace-gpu code called the registration at mmap, exposing it
> to corruption. This may happen, when multiple mmap were called on the
> same BAR. This issue was also noticed by Linus Torvalds who reverted
> the patch [2].
> 
> This patch series addresses those issues.
> 
> Patch 1/3 fixes the first issue by translating PFN to page offset
> and using that information to send the SIGBUS to the mapping process.
> Patch 2/3 add stubs for CONFIG_MEMORY_FAILURE disabled.
> Patch 3/3 is a resend of the reverted change to register the device
> memory at the time of open instead of mmap.
> 

Strictly speaking, [1/3] is suitable for merging in the 6.19-rcX cycle
because it fixes a 6.19-rcX thing.  But [2/3] and [3/3] don't fix
anything and hence should be considered 6.20-rc1 material.  Yes?

So unless I'm missing something, I'll grab [1/3] as a 6.19-rcX hotfix. 
Please prepare the other two patches as a standalone series for
addition to mm.git after 6.19-rc1 is released.

Thanks.
Re: [PATCH v1 0/3] mm: fixup pfnmap memory failure handling
Posted by Jason Gunthorpe 4 days, 9 hours ago
On Thu, Dec 11, 2025 at 12:11:19PM -0800, Andrew Morton wrote:
> On Thu, 11 Dec 2025 07:06:00 +0000 <ankita@nvidia.com> wrote:
> 
> > It was noticed during 6.19 merge window that the patch series [1] to
> > introduce memory failure handling for the PFNMAP memory is broken.
> > 
> > The expected behaviour of the series is to allow a driver (such as
> > nvgrace-gpu) to register its device memory with the mm. The mm would
> > then handle the poison on that registered memory region.
> > 
> > However, the following issues were identified in the patch series.
> > 1. Faulty use of PFN instead of mapping file page offset to derive
> > the usermode process VA corresponding to the mapping to PFN.
> > 2. nvgrace-gpu code called the registration at mmap, exposing it
> > to corruption. This may happen, when multiple mmap were called on the
> > same BAR. This issue was also noticed by Linus Torvalds who reverted
> > the patch [2].
> > 
> > This patch series addresses those issues.
> > 
> > Patch 1/3 fixes the first issue by translating PFN to page offset
> > and using that information to send the SIGBUS to the mapping process.
> > Patch 2/3 add stubs for CONFIG_MEMORY_FAILURE disabled.
> > Patch 3/3 is a resend of the reverted change to register the device
> > memory at the time of open instead of mmap.
> > 
> 
> Strictly speaking, [1/3] is suitable for merging in the 6.19-rcX cycle
> because it fixes a 6.19-rcX thing.  But [2/3] and [3/3] don't fix
> anything and hence should be considered 6.20-rc1 material.  Yes?

Well, technically, none of this is "rc" because Linus removed the only
user in the merge..
 
> So unless I'm missing something, I'll grab [1/3] as a 6.19-rcX hotfix. 
> Please prepare the other two patches as a standalone series for
> addition to mm.git after 6.19-rc1 is released.

The plan was to unrevert the revert that Linus did during the merge
while the merge window is still open as an alternative bug fix to the
revert that Linus did.

So it would be great if you could grab this for the trailing merge
window period.

Jason