Felix Kuehling wrote: > [+Yang.Lee <yang.lee@xxxxxxxxxxxxxxxxx>] > > On 2022-10-21 15:26, Andrew Morton wrote: > > > The patch titled > > Subject: mm/memremap: Introduce pgmap_request_folio() using pgmap offsets > > has been added to the -mm mm-unstable branch. Its filename is > > mm-memremap-introduce-pgmap_request_folio-using-pgmap-offsets.patch > > > > This patch will shortly appear at > > https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-memremap-introduce-pgmap_request_folio-using-pgmap-offsets.patch > > > > This patch will later appear in the mm-unstable branch at > > git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm > > > > Before you just go and hit "reply", please: > > a) Consider who else should be cc'ed > > b) Prefer to cc a suitable mailing list as well > > c) Ideally: find the original patch on the mailing list and do a > > reply-to-all to that, adding suitable additional cc's > > > > *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** > > > > The -mm tree is included into linux-next via the mm-everything > > branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm > > and is updated there every 2-3 working days > > > > ------------------------------------------------------ > > From: Dan Williams <dan.j.williams@xxxxxxxxx> > > Subject: mm/memremap: Introduce pgmap_request_folio() using pgmap offsets > > Date: Thu, 20 Oct 2022 14:56:39 -0700 > > > > A 'struct dev_pagemap' (pgmap) represents a collection of ZONE_DEVICE > > pages. The pgmap is a reference counted object that serves a similar > > role as a 'struct request_queue'. Live references are obtained for each > > in flight request / page, and once a page's reference count drops to > > zero the associated pin of the pgmap is dropped as well. While a page is > > idle nothing should be accessing it because that is effectively a > > use-after-free situation. Unfortunately, all current ZONE_DEVICE > > implementations deploy a layering violation to manage requests to > > activate pages owned by a pgmap. Specifically, they take steps like walk > > the pfns that were previously assigned at memremap_pages() time and use > > pfn_to_page() to recall metadata like page->pgmap, or make use of other > > data like page->zone_device_data. > > > > The first step towards correcting that situation is to provide a > > API to get access to a pgmap page that does not require the caller to > > know the pfn, nor access any fields of an idle page. Ideally this API > > would be able to support dynamic page creation instead of the current > > status quo of pre-allocating and initializing pages. > > > > On a prompt from Jason, introduce pgmap_request_folio() that operates on > > an offset into a pgmap. It replaces the shortlived > > pgmap_request_folios() that was continuing the layering violation of > > assuming pages are available to be consulted before asking the pgmap to > > make them available. > > > > For now this only converts the callers to lookup the pgmap and generate > > the pgmap offset, but it does not do the deeper cleanup of teaching > > those call sites to generate those arguments without walking the page > > metadata. For next steps it appears the DEVICE_PRIVATE implementations > > could plumb the pgmap into the necessary callsites and switch to using > > gen_pool_alloc() to track which offsets of a pgmap are allocated. For > > DAX, dax_direct_access() could switch from returning pfns to returning > > the associated @pgmap and @pgmap_offset. Those changes are saved for > > follow-on work. > > > > Link: https://lkml.kernel.org/r/166630293549.1017198.3833687373550679565.stgit@xxxxxxxxxxxxxxxxxxxxxxxxx > > Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> > > Suggested-by: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Acked-by: Felix Kuehling <Felix.Kuehling@xxxxxxx> > > Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx> > > Cc: Jan Kara <jack@xxxxxxx> > > Cc: "Darrick J. Wong" <djwong@xxxxxxxxxx> > > Cc: Christoph Hellwig <hch@xxxxxx> > > Cc: John Hubbard <jhubbard@xxxxxxxxxx> > > Cc: Alistair Popple <apopple@xxxxxxxxxx> > > Cc: Alex Deucher <alexander.deucher@xxxxxxx> > > Cc: "Christian König" <christian.koenig@xxxxxxx> > > Cc: "Pan, Xinhui" <Xinhui.Pan@xxxxxxx> > > Cc: David Airlie <airlied@xxxxxxxx> > > Cc: Daniel Vetter <daniel@xxxxxxxx> > > Cc: Ben Skeggs <bskeggs@xxxxxxxxxx> > > Cc: Karol Herbst <kherbst@xxxxxxxxxx> > > Cc: Lyude Paul <lyude@xxxxxxxxxx> > > Cc: "Jérôme Glisse" <jglisse@xxxxxxxxxx> > > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > [snip] > > --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c~mm-memremap-introduce-pgmap_request_folio-using-pgmap-offsets > > +++ a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c > [snip] > > @@ -325,7 +328,8 @@ svm_migrate_copy_to_vram(struct amdgpu_d > > > > dst[i] = cursor.start + (j << PAGE_SHIFT); > > migrate->dst[i] = svm_migrate_addr_to_pfn(adev, dst[i]); > > - svm_migrate_get_vram_page(prange, migrate->dst[i]); > > + svm_migrate_get_vram_page(&kfddev->pgmap, prange, > > + migrate->dst[i]); > > Yang Lee pointed out that the indentation was broken here. I don't know > what to do with his patch because it doesn't apply to the branches I > work on. What's the best way to fix this before it goes to Linus' master > branch? Send a patch relative to mm-unstable, like a typical Fixes: patch, and Andrew will roll it in / squash it when it is time for this work to roll from mm-unstable to mm-stable. ...and apologies for the whitespace corruption, I missed that mistake.
