[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aTtQTj98gZBgaVXV@nvidia.com>
Date: Thu, 11 Dec 2025 19:14:22 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: ankita@...dia.com, vsethi@...dia.com, mochs@...dia.com,
skolothumtho@...dia.com, alex@...zbot.org, linmiaohe@...wei.com,
nao.horiguchi@...il.com, cjia@...dia.com, zhiw@...dia.com,
kjaju@...dia.com, yishaih@...dia.com, kevin.tian@...el.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH v1 0/3] mm: fixup pfnmap memory failure handling
On Thu, Dec 11, 2025 at 12:11:19PM -0800, Andrew Morton wrote:
> On Thu, 11 Dec 2025 07:06:00 +0000 <ankita@...dia.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
Powered by blists - more mailing lists