Re: [PATCH v2] drivers/virt/fsl_hypervisor: Correcting error handling path

d probably good to add a Fixes: tag, too. More: This will address both. Signed-off-by: Souptick Joarder Reviewed-by: Dan Carpenter Cc: John Hubbard --- v2: Added review tag. drivers/virt/fsl_hypervisor.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/d

Re: [PATCH] mm: Skip opportunistic reclaim for dma pinned pages

ugh. And I *think* it's actually safe to do this, as it stays away from writeback or other filesystem activity. But let me double check that, in case I'm forgetting something. thanks, -- John Hubbard NVIDIA

Re: [PATCH] mm: Skip opportunistic reclaim for dma pinned pages

t/lists/linux-mm/msg142700.html thanks, -- John Hubbard NVIDIA

Re: [PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*()

.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: Souptick Joarder Cc: John Hubbard Cc: Boris Ostrovsky Cc: Paul Durrant --- Hi, I'm compile tested this, but unable to run-time test, so any testing help is much appriciated.

[PATCH v2] vfio/spapr_tce: convert get_user_pages() --> pin_user_pages()

Cornelia Huck Cc: k...@vger.kernel.org Signed-off-by: John Hubbard --- Hi, Changes since v1: rebased onto Linux-5.8-rc2. thanks, John Hubbard drivers/vfio/vfio_iommu_spapr_tce.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vf

[PATCH v2 0/1] infiniband/mm: convert put_page() to put_user_page*()

From: John Hubbard Hi Jason and all, I've added Jerome's and Ira's Reviewed-by tags. Other than that, this patch is the same as v1. == Earlier cover letter: IIUC, now that we have the put_user_pages() merged

[PATCH v2] infiniband/mm: convert put_page() to put_user_page*()

From: John Hubbard For infiniband code that retains pages via get_user_pages*(), release those pages via the new put_user_page(), or put_user_pages*(), instead of put_page() This is a tiny part of the second step of fixing the problem described in [1]. The steps are: 1) Provide put_user_page

Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal

em? Or is there more that must be done? 3. Christophe Hellwig's unified gup patchset wreaks havoc in gup.c, and will conflict violently, as I'm sure you noticed. :) thanks, -- John Hubbard NVIDIA > > A general overview follows for background. > > It should be noted that one soluti

Re: [PATCH 12/16] mm: consolidate the get_user_pages* implementations

uot;RDMA/FS DAX truncate proposal"). thanks, -- John Hubbard NVIDIA > Signed-off-by: Christoph Hellwig > --- > mm/Kconfig | 1 + > mm/Makefile | 4 +- > mm/gup.c| 476 +--- > mm/nommu.c | 88 -- > mm/uti

Re: [PATCH 12/16] mm: consolidate the get_user_pages* implementations

On 6/5/19 11:20 PM, Christoph Hellwig wrote: On Wed, Jun 05, 2019 at 11:01:17PM -0700, John Hubbard wrote: I started reviewing this one patch, and it's kind of messy figuring out if the code motion preserves everything because of all the consolidation from other places, plus having to move

Re: [PATCHv2 1/2] mm/gup: fix omission of check on FOLL_LONGTERM in get_user_pages_fast()

ink this is getting narrowed down to, messages from nvidia.com (or at least from me) are not making it onto the lkml list server. I'm told that this can actually happen *because* of DKIM domains: list servers may try to avoid retransmitting from DKIM domains. sigh. Any hints are welcome

Re: [PATCH v3] mm/swap: Fix release_pages() when releasing devmap pages

the new put_user_pages() could be interchangeable.[1] > > [1] > https://lore.kernel.org/lkml/20190523172852.ga27...@iweiny-desk2.sc.intel.com/ > > Cc: Jérôme Glisse > Cc: Michal Hocko > Reviewed-by: Dan Williams > Reviewed-by: John Hubbard > Signed-off-by: Ira Weiny

Re: [PATCH v3] mm/swap: Fix release_pages() when releasing devmap pages

On 6/4/19 1:11 PM, Dan Williams wrote: > On Tue, Jun 4, 2019 at 12:48 PM John Hubbard wrote: >> >> On 6/4/19 9:48 AM, ira.we...@intel.com wrote: >>> From: Ira Weiny >>> ... >>> diff --git a/mm/swap.c b/mm/swap.c >>> index 7ede3eddc12a..6d153ce4

Re: [PATCH hmm v2 2/5] mm/hmm: make hmm_range_fault return 0 or -1

ill at their input * values. */ Either way, Reviewed-by: John Hubbard thanks, -- John Hubbard NVIDIA } while (ret == -EBUSY); - - if (ret) - return ret; - return (hmm_vma_walk.last - range->start) >> PAGE_SHIFT; + retu

Re: [PATCH hmm v2 4/5] mm/hmm: remove HMM_PFN_SPECIAL

On 2020-05-01 11:20, Jason Gunthorpe wrote: From: Jason Gunthorpe This is just an alias for HMM_PFN_ERROR, nothing cares that the error was because of a special page vs any other error case. Reviewed-by: John Hubbard thanks, -- John Hubbard NVIDIA Acked-by: Felix Kuehling Reviewed

Re: [PATCH hmm v2 5/5] mm/hmm: remove the customizable pfn format from hmm_range_fault

return 0; - return pmd_write(pmd) ? range->flags[HMM_PFN_VALID] | - range->flags[HMM_PFN_WRITE] : - range->flags[HMM_PFN_VALID]; + return pmd_write(pmd) ? (HMM_PFN_VALID | HMM_PFN_WRITE) : HMM_PFN_VALID; I

Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

return -EFAULT; ...although I might be missing some other things that need a similar change, so you should look carefully for yourself. Once that change (and anything I missed) is in place, then you could go ahead and stop handling ret==0 cases at the call sites. thanks, -- John Hubbard NVIDIA

Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

On 2020-05-05 13:36, Souptick Joarder wrote: On Wed, May 6, 2020 at 1:08 AM John Hubbard wrote: On 2020-05-05 12:14, Souptick Joarder wrote: Currently {get|pin}_user_pages_fast() have 3 return value 0, -errno and no of pinned pages. The only case where these two functions will return 0

Re: [RFC] mm/vmstat: Add events for THP migration without split

n today's exact code. Maybe Zi Yan's recommended name is exactly right, in fact: THP_PMD_MIGRATION_SUCCESS thanks, -- John Hubbard NVIDIA 2. With split pgmigrate_success 512 pgmigrate_fail 0 thp_pmd_migration_entry_set 0 thp_pmd_migr

[PATCH 1/1] mm/gup_benchmark: fix MAP_HUGETLB case

e problem is that the user space program, gup_benchmark.c, really just wants anonymous memory here. The simplest way to get that is to pass MAP_ANONYMOUS whenever MAP_HUGETLB is specified, so that's what this patch does. Cc: Keith Busch Signed-off-by: John Hubbard --- tools/testing/selftests/vm/g

[PATCH 0/1] mm/gup_benchmark: fix MAP_HUGETLB case

MAP_ANONYMOUS for the MAP_HUGETLB case. However, another way to do it might be to mmap() against a valid hugetlb page file, instead of /dev/zero. But that seems like a lot of trouble and if I'm reading the intent correctly, MAP_ANONYMOUS is what's desired anyway. John Hubbard (1): mm/gup_benchmark

Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

, on the contrary: there are call site where returning 0 after being requested to pin zero pages, helps simplify the code. For example, if they're just doing math such as "if(nr_expected != nr_pages_pinned) ...". This looks like a complete dead end, sorry. thanks, -- John Hubbard NVIDIA

[PATCH 2/2] selftests/vm/.gitignore: add mremap_dontunmap

Add mremap_dontunmap to .gitignore. Fixes: 0c28759ee3c9 ("selftests: add MREMAP_DONTUNMAP selftest") Cc: Brian Geffon Signed-off-by: John Hubbard --- tools/testing/selftests/vm/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/vm/.gitignore b/too

[PATCH 0/2] selftests/vm: minor fixes for 5.7-rc5

erent item ("khugepaged") to the *bottom* of .gitignore. * The write_to_hugetlbfs.c fix is already applied to linux-next, but doesn't seem to be getting picked up for linux.git. Maybe it's in the merge pipeline, but if not, let's fix it here, before the -rc cycle is over. John Hubb

[PATCH 1/2] selftests/vm/write_to_hugetlbfs.c: fix unused variable warning

Remove unused variable "i", which was triggering a compiler warning. Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Cc: Mina Almasry Signed-off-by: John Hubbard --- tools/testing/selftests/vm/write_to_hugetlbfs.c | 2 -- 1 file changed, 2 dele

[PATCH 1/1] selftests/vm/.gitignore: add khugepaged, mremap_dontunmap

Add mremap_dontunmap and khugepaged to .gitignore. Fixes: 6582dba23f8b ("khugepaged: add self test") Fixes: 0c28759ee3c9 ("selftests: add MREMAP_DONTUNMAP selftest") Cc: Kirill A. Shutemov Cc: Brian Geffon Signed-off-by: John Hubbard --- tools/testing/selftests/vm/.giti

[PATCH 0/1] selftests/vm: .gitignore fixes for mmotm

This approach allows merging to work without manual intervention in this case. [1] https://lore.kernel.org/r/20200517001245.361762-3-jhubb...@nvidia.com John Hubbard (1): selftests/vm/.gitignore: add khugepaged, mremap_dontunmap tools/testing/selftests/vm/.gitignore | 2 ++ 1 file changed, 2

[PATCH] fpga: dfl: afu: convert get_user_pages() --> pin_user_pages()

Fischer Cc: linux-f...@vger.kernel.org Signed-off-by: John Hubbard --- drivers/fpga/dfl-afu-dma-region.c | 15 +++ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/fpga/dfl-afu-dma-region.c b/drivers/fpga/dfl-afu-dma-region.c index 62f924489db5..84f696d5ba82 10064

[PATCH] rds: convert get_user_pages() --> pin_user_pages()

ub Kicinski Cc: net...@vger.kernel.org Cc: linux-r...@vger.kernel.org Cc: rds-de...@oss.oracle.com Signed-off-by: John Hubbard --- net/rds/info.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/net/rds/info.c b/net/rds/info.c index 03f6fd56d237..e1d63563e81c 100644

[PATCH] oradax: convert get_user_pages() --> pin_user_pages()

Miller Cc: sparcli...@vger.kernel.org Signed-off-by: John Hubbard --- drivers/sbus/char/oradax.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/sbus/char/oradax.c b/drivers/sbus/char/oradax.c index 8af216287a84..21b7cb6e7e70 100644 --- a/drivers/sbus/char/oradax.c +++

[PATCH 1/2] rapidio: fix an error in get_user_pages_fast() error handling

successfully pinned are released. Fixes: e8de370188d0 ("rapidio: add mport char device driver") Cc: Matt Porter Cc: Alexandre Bounine Cc: Sumit Semwal Cc: Dan Carpenter Cc: Andrew Morton Cc: linux-me...@vger.kernel.org Cc: sta...@vger.kernel.org Signed-off-by: John Hubbard --- drivers/rapid

[PATCH 2/2] rapidio: convert get_user_pages() --> pin_user_pages()

lexandre Bounine Cc: Sumit Semwal Cc: Dan Carpenter Cc: Andrew Morton Cc: linux-me...@vger.kernel.org Signed-off-by: John Hubbard --- drivers/rapidio/devices/rio_mport_cdev.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/rapidio/devices/rio_mport_cdev.

[PATCH 0/2] rapidio: convert to pin_user_pages(), plus a small fix

-compiling for half a dozen arches. John Hubbard (2): rapidio: fix an error in get_user_pages_fast() error handling rapidio: convert get_user_pages() --> pin_user_pages() drivers/rapidio/devices/rio_mport_cdev.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-)

[PATCH 1/2] mm/gup: introduce pin_user_pages_unlocked

Introduce pin_user_pages_unlocked(), which is nearly identical to the get_user_pages_unlocked() that it wraps, except that it sets FOLL_PIN and rejects FOLL_GET. Signed-off-by: John Hubbard --- include/linux/mm.h | 2 ++ mm/gup.c | 17 + 2 files changed, 19 insertions

[PATCH 0/2] mm/gup, media/ivtv: introduce pin_user_pages_unlocked

, although that does also include cross-compiling for half a dozen arches. John Hubbard (2): mm/gup: introduce pin_user_pages_unlocked ivtv: convert get_user_pages() --> pin_user_pages() drivers/media/pci/ivtv/ivtv-udma.c | 19 ++- drivers/media/pci/ivtv/ivtv-yuv.c |

[PATCH 2/2] ivtv: convert get_user_pages() --> pin_user_pages()

basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: John Hubbard --- dr

[PATCH] genwqe: convert get_user_pages() --> pin_user_pages()

mann Cc: Greg Kroah-Hartman Signed-off-by: John Hubbard --- Hi, Note that I have only compile-tested this patch, although that does also include cross-compiling for a few other arches...but it only seemed to be supported on x86_64 and sparc, for those. thanks, John Hubbard NVIDIA drivers/misc/genw

[PATCH] drivers/mic/scif: convert get_user_pages() --> pin_user_pages()

[3] https://lore.kernel.org/r/20190723153640.gb...@lst.de Signed-off-by: John Hubbard --- Hi, Note that I have only compile-tested this patch, although that does also include cross-compiling for a few other arches. thanks, John Hubbard NVIDIA drivers/misc/mic/scif/scif_rma.c | 26

[PATCH] drm/etnaviv: convert get_user_pages() --> pin_user_pages()

basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: John Hubbard --- Hi, N

[PATCH] orangefs: convert get_user_pages() --> pin_user_pages()

basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: John Hubbard ---

Re: [PATCH] orangefs: convert get_user_pages() --> pin_user_pages()

On 2020-05-17 23:01, John Hubbard wrote: This code was using get_user_pages*(), in a "Case 2" scenario (DMA/RDMA), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_user_pages*() + unpin_user_pages() calls. Oops

Re: [RFC V2] mm/vmstat: Add events for PMD based THP migration without split

NFIG_ARCH_ENABLE_THP_MIGRATION + "thp_pmd_migration_success", + "thp_pmd_migration_failure", +#endif #endif #ifdef CONFIG_MEMORY_BALLOON "balloon_inflate", thanks, -- John Hubbard NVIDIA

Re: [RFC] mm/gup.c: Use gup_flags as parameter instead of passing write flag

with what I'm doing here. So, how would you like proceed? If you want to do the full conversion (which really should include the call sites), it would be easier for me if you based it on my upcoming small patchset, which I expect to post shortly (later today). thanks, -- John Hubbard NVIDIA

Re: [RFC] mm/gup.c: Use gup_flags as parameter instead of passing write flag

full conversion in a single commit. But if it is not preferred way, I would go as per feedback. Thanks, I appreciate it! And yes, you'll want to do the "write" to "gup_flags" conversion in a single patch, definitely. thanks, -- John Hubbard NVIDIA

[PATCH] mm/gup: remove unused variable in siw_free_plist()

From: John Hubbard Commit 63630f9a8d72 ("mm/gup: add make_dirty arg to put_user_pages_dirty_lock()") removed the only user of the local variable p. Finish the job by removing p as well. Fixes: 63630f9a8d72 ("mm/gup: add make_dirty arg to put_user_pages_dirty_lock()")

Re: [PATCH 1/2] KVM: SVM: fix svn_pin_memory()'s use of get_user_pages_fast()

uld be more willing to pick them up. Any testing help there is greatly appreciated! thanks, -- John Hubbard NVIDIA

Re: [PATCH v4 26/26] mm/gup: Remove task_struct pointer for all gup code

| 2 +- 18 files changed, 65 insertions(+), 82 deletions(-) Looks good: Reviewed-by: John Hubbard One minor refinement: in gup.c, if you add the following hunk on top of your changes, that will eradicate the last reference to struct task, in that file: diff --git a/mm/gup.c b/mm/gup.c

Re: [PATCH v2 2/3] xen/privcmd: Mark pages as dirty

even though the call site conversions are nearly done. thanks, -- John Hubbard NVIDIA

Re: [PATCH V3] mm/vmstat: Add events for THP migration without split

le to have? No, they are not. And there are a couple more pre-existing cases as well, right above what can be seen here (this patch just follows the local pattern) that should also be removed. thanks, -- John Hubbard NVIDIA

Re: [PATCH V3] mm/vmstat: Add events for THP migration without split

Cc: Zi Yan Cc: John Hubbard Cc: Naoya Horiguchi Cc: Andrew Morton Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Zi Yan Signed-off-by: Anshuman Khandual This is missing the Documentation/ Cc's, did you run scripts/get_maintainer.pl? I'm adding linux-doc

Re: [PATCH V4] mm/vmstat: Add events for THP migration without split

, a migration retry was used for it's sub-pages. Just a documentation nit: "its sub-pages", not "it's sub-pages". thanks, -- John Hubbard NVIDIA

Re: [PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*()

On 2020-06-25 22:26, Souptick Joarder wrote: On Thu, Jun 25, 2020 at 11:19 AM John Hubbard wrote: On 2020-06-24 20:02, Souptick Joarder wrote: ... @@ -612,13 +612,7 @@ static int lock_pages( static void unlock_pages(struct page *pages[], unsigned int nr_pages) { - unsigned int i

Re: [PATCH] nouveau: fix page fault on device private memory

-5.8.0-rc2 and is for Ben Skeggs nouveau tree. It doesn't depend on any of the other nouveau/HMM changes I have recently posted. Maybe cc stable, seeing as how the problem affect Linux 5.7? thanks, -- John Hubbard NVIDIA drivers/gpu/drm/nouveau/nouveau_svm.c | 1 + 1 file changed, 1 insertion(+)

Re: [PATCH 01/26] mm: Do page fault accounting in handle_mm_fault

e a number of changes to mm/gup.c (not a concern for this patch, but it is for the overall series). So I'm hoping you're going to post a version that is rebased against 5.8-rc*. thanks, -- John Hubbard NVIDIA

Re: [PATCH 13/16] mm: support THP migration to device private memory

ck to base page OK, but *all* page entries (base and huge/large pages) need to be cleared, when migrating to device memory, unless I'm really confused here. So: not CoW. thanks, -- John Hubbard NVIDIA

Re: [RESEND PATCH 2/3] nouveau: fix mixed normal and device private page migration

cription, right? (It feels like a casualty of rearranging the patches.) thanks, -- John Hubbard NVIDIA

Re: [RESEND PATCH 1/3] nouveau: fix migrate page regression

r for maintenance, too, because the function never intends to migrate "some number of bytes". It intends to migrate exactly one page. Hope I'm not missing something fundamental, but: Reviewed-by: John Hubbard

Re: [RESEND PATCH 3/3] nouveau: make nvkm_vmm_ctor() and nvkm_mmu_ptp_get() static

*, u64 addr, u64 size); Looks accurate: the order within vmm.c (now that there is no .h declaration) is still good, and I found no other uses of either function within the linux.git tree, so Reviewed-by: John Hubbard

Re: [PATCH] docs: mm/gup: Minor documentation update

On 2020-06-17 12:27, Souptick Joarder wrote: Now there are 5 cases. Updated the same. Signed-off-by: Souptick Joarder Cc: John Hubbard --- Documentation/core-api/pin_user_pages.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/core-api/pin_user_pages.rst

Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*()

er. unpin_user_pages() is the right place to do so. John any thought ? So far I haven't seen any cases to justify changing the implementation of unpin_user_pages(). thanks, -- John Hubbard NVIDIA

Re: [PATCH 1/2] docs: mm/gup: pin_user_pages.rst: add a "case 5"

On 2020-06-12 12:24, Matthew Wilcox wrote: On Fri, May 29, 2020 at 04:43:08PM -0700, John Hubbard wrote: +CASE 5: Pinning in order to write to the data within the page +- +Even though neither DMA nor Direct IO is involved, just

[PATCH] rds: fix crash in rds_info_getsockopt()

;) Cc: David S. Miller Cc: Jakub Kicinski Cc: net...@vger.kernel.org Cc: linux-r...@vger.kernel.org Cc: rds-de...@oss.oracle.com Signed-off-by: John Hubbard --- net/rds/info.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/rds/info.c b/net/rds/info.c index

Re: [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()

On 2020-05-21 11:57, Chris Wilson wrote: Quoting John Hubbard (2020-05-19 01:21:20) This needs to go through Andrew's -mm tree, due to adding a new gup.c routine. However, I would really love to have some testing from the drm/i915 folks, because I haven't been able to run-time test that part

Re: [PATCH] scsi: st: convert convert get_user_pages() --> pin_user_pages()

On 2020-05-21 12:47, Bart Van Assche wrote: On 2020-05-18 21:55, John Hubbard wrote: This code was using get_user_pages*(), in a "Case 2" scenario (DMA/RDMA), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_

Solved: [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()

On 2020-05-21 12:11, John Hubbard wrote: On 2020-05-21 11:57, Chris Wilson wrote: Quoting John Hubbard (2020-05-19 01:21:20) This needs to go through Andrew's -mm tree, due to adding a new gup.c routine. However, I would really love to have some testing from the drm/i915 folks, because I

[PATCH] mm/gup: fixup gup.c for "mm/gup: refactor and de-duplicate gup_fast() code"

ko Ursulin Signed-off-by: John Hubbard --- Hi Andrew, Chris, Andrew: This is a fixup that applies to today's (20200521) linux-next. In that tree, this fixes up: commit dfb8dfe80808 ("mm/gup: refactor and de-duplicate gup_fast() code") Chris: I'd like to request another CI run for the

[PATCH] mm/gup: might_lock_read(mmap_sem) in get_user_pages_fast()

Lespinasse Cc: Jason Gunthorpe Signed-off-by: John Hubbard --- Hi Andrew, This applies on top of [1], which in turn applies to today's (20200521) linux-next. As noted in the discussion [2], this will need changing from mmap_sem to mmap_lock, after Michel Lespinasse's patchset arrives. [1

Re: [PATCH] mm/gup: fixup gup.c for "mm/gup: refactor and de-duplicate gup_fast() code"

On 2020-05-21 19:46, Chris Wilson wrote: Quoting John Hubbard (2020-05-22 00:38:41) Include FOLL_FAST_ONLY in the list of flags to *not* WARN() on, in internal_get_user_pages_fast(). Cc: Chris Wilson Cc: Daniel Vetter Cc: David Airlie Cc: Jani Nikula Cc: "Joonas Lahtinen" Cc: Ma

[PATCH 0/2] video: fbdev: fix error handling, convert to pin_user_pages*()

Vetter Cc: Gustavo A. R. Silva Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org John Hubbard (2): video: fbdev: fix error handling for get_user_pages_fast() video: fbdev: convert get_user_pages() --> pin_user_pages() drivers/video/fbdev/

[PATCH 2/2] video: fbdev: convert get_user_pages() --> pin_user_pages()

Bergmann Cc: Daniel Vetter Cc: Gustavo A. R. Silva Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Signed-off-by: John Hubbard --- drivers/video/fbdev/pvr2fb.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/pvr2

[PATCH 1/2] video: fbdev: fix error handling for get_user_pages_fast()

get one. And explain this with comments, seeing as how it is error-prone. Cc: Bartlomiej Zolnierkiewicz Cc: Arnd Bergmann Cc: Daniel Vetter Cc: Gustavo A. R. Silva Cc: Jani Nikula Cc: dri-de...@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Signed-off-by: John Hubbard --- drivers/video

[PATCH v2 3/4] mm/gup: introduce pin_user_pages_fast_only()

This is the FOLL_PIN equivalent of __get_user_pages_fast(), except with a more descriptive name, and gup_flags instead of a boolean "write" in the argument list. Signed-off-by: John Hubbard --- include/linux/mm.h | 2 ++ mm/gup.c | 36 +++

[PATCH v2 4/4] drm/i915: convert get_user_pages() --> pin_user_pages()

basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: John Hubbard --- driv

[PATCH v2 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()

to change the name as well, to whatever the consensus is. My initial recommendation is: get_user_pages_fast_only(), to match the new pin_user_pages_only(). John Hubbard (4): mm/gup: move __get_user_pages_fast() down a few lines in gup.c mm/gup: refactor and de-duplicate gup_fast() code mm

[PATCH v2 1/4] mm/gup: move __get_user_pages_fast() down a few lines in gup.c

This is in order to avoid a forward declaration of internal_get_user_pages_fast(), in the next patch. This is code movement only--all generated code should be identical. Signed-off-by: John Hubbard --- mm/gup.c | 112 +++ 1 file changed, 56

[PATCH v2 2/4] mm/gup: refactor and de-duplicate gup_fast() code

f enabling interrupts was fragile at best. Signed-off-by: John Hubbard --- include/linux/mm.h | 1 + mm/gup.c | 63 ++ 2 files changed, 31 insertions(+), 33 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index a5

Re: [PATCH] staging: kpc2000: kpc_dma: Convert get_user_pages() --> pin_user_pages()

On 2020-06-08 12:01, Souptick Joarder wrote: On Mon, Jun 1, 2020 at 7:15 AM John Hubbard wrote: On 2020-05-31 10:51, Souptick Joarder wrote: In 2019, we introduced pin_user_pages*() and now we are converting get_user_pages*() to the new API as appropriate. [1] & [2] could be refe

Re: [PATCH] staging: kpc2000: kpc_dma: Convert get_user_pages() --> pin_user_pages()

On 2020-06-08 12:16, Dan Carpenter wrote: On Mon, Jun 08, 2020 at 12:05:57PM -0700, John Hubbard wrote: On 2020-06-08 12:01, Souptick Joarder wrote: On Mon, Jun 1, 2020 at 7:15 AM John Hubbard wrote: On 2020-05-31 10:51, Souptick Joarder wrote: In 2019, we introduced pin_user_pages

Re: [PATCH 0/2] mm: put_user_page() call site conversion first

On 2/14/19 4:23 PM, Ira Weiny wrote: > On Thu, Feb 07, 2019 at 11:56:47PM -0800, john.hubb...@gmail.com wrote: >> From: John Hubbard [...] >> mm: introduce put_user_page*(), placeholder versions >> infiniband/mm: convert put_page() to put_user_page*() > > A bit la

Re: [v2 PATCH] mm: ksm: do not block on page lock when searching stable tree

troubleshooting on your end:0 https://lore.kernel.org/lkml/aecc642c-d485-ed95-7935-19cda4880...@nvidia.com/ thanks, -- John Hubbard NVIDIA > > On Wed, Jan 23, 2019 at 4:24 PM John Hubbard wrote: >> >> On 1/23/19 3:52 PM, Yang Shi wrote: >>> ksmd need search stable tre

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

st() path. But I >> still don't think anything special (i.e. page lock or new barrier) is >> necessary. GUP_fast() takes care already now that it cannot race with page >> unmapping or write-protection (as there are other places in MM that rely on >> this). Look, gup_pte_range() has: >> >> if (!page_cache_get_speculative(head)) >> goto pte_unmap; >> >> if (unlikely(pte_val(pte) != pte_val(*ptep))) { >> put_page(head); >> goto pte_unmap; >> } >> >> So that page_cache_get_speculative() will become >> page_cache_pin_speculative() to increment refcount by PAGE_PIN_BIAS instead >> of 1. That is atomic ordered operation so it cannot be reordered with the >> following check that PTE stayed same. So once page_mkclean() write-protects >> PTE, there can be no new pins from GUP_fast() and we are sure all >> succeeding pins are visible in page->_refcount after page_mkclean() >> completes. Again this is nothing new, other mm code already relies on >> either seeing page->_refcount incremented or GUP fast bailing out (e.g. DAX >> relies on this). Although strictly speaking I'm not 100% sure what prevents >> page->_refcount load to be speculatively reordered before PTE update even >> in current places using this but there's so much stuff inbetween that >> there's probably something ;). But we could add smp_rmb() after >> page_mkclean() before changing page_pinned() for the peace of mind I guess. > > Yeah i think you are right, i missed the check on same pte value > and the atomic inc in page_cache_get_speculative() is a barrier. > I do not think the barrier would be necessary as page_mkclean is > taking and dropping locks so those should have enough barriering. > Hi Jan, Jerome, OK, this seems to be up and running locally, but while putting together documentation and polishing up things, I noticed that there is one last piece that I don't quite understand, after all. The page_cache_get_speculative() existing documentation explains how refcount synchronizes these things, but I don't see how that helps with synchronization page_mkclean and gup, in this situation: gup_fast gets the refcount and rechecks the pte hasn't changed meanwhile, page_mkclean...wait, how does refcount come into play here? page_mkclean can remove the mapping and insert a write-protected pte, regardless of page refcount, correct? Help? :) thanks, -- John Hubbard NVIDIA

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

On 1/28/19 5:23 PM, Jerome Glisse wrote: On Mon, Jan 28, 2019 at 04:22:16PM -0800, John Hubbard wrote: On 1/23/19 11:04 AM, Jerome Glisse wrote: On Wed, Jan 23, 2019 at 07:02:30PM +0100, Jan Kara wrote: On Tue 22-01-19 11:46:13, Jerome Glisse wrote: On Tue, Jan 22, 2019 at 04:24:59PM +0100

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

On 1/14/19 9:21 AM, Jerome Glisse wrote: > On Mon, Jan 14, 2019 at 03:54:47PM +0100, Jan Kara wrote: >> On Fri 11-01-19 19:06:08, John Hubbard wrote: >>> On 1/11/19 6:46 PM, Jerome Glisse wrote: >>>> On Fri, Jan 11, 2019 at 06:38:44PM -0800, John Hubbard wrote: >

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

On 1/15/19 12:34 AM, Jan Kara wrote: > On Mon 14-01-19 11:09:20, John Hubbard wrote: >> On 1/14/19 9:21 AM, Jerome Glisse wrote: >>>> [...] > >> For example, the following already survives a basic boot to graphics mode. >> It requires a bunch of callsite c

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

On 1/15/19 9:15 AM, Jerome Glisse wrote: > On Tue, Jan 15, 2019 at 09:07:59AM +0100, Jan Kara wrote: >> On Mon 14-01-19 12:21:25, Jerome Glisse wrote: >>> On Mon, Jan 14, 2019 at 03:54:47PM +0100, Jan Kara wrote: >>>> On Fri 11-01-19 19:06:08, John Hubbard wrote: &g

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

On 1/15/19 2:12 PM, Jerome Glisse wrote: > On Tue, Jan 15, 2019 at 01:56:51PM -0800, John Hubbard wrote: >> On 1/15/19 9:15 AM, Jerome Glisse wrote: >>> On Tue, Jan 15, 2019 at 09:07:59AM +0100, Jan Kara wrote: >>>> On Mon 14-01-19 12:21:25, Jerome Glisse wrote: >&

[PATCH 1/6] mm: introduce put_user_page*(), placeholder versions

From: John Hubbard Introduces put_user_page(), which simply calls put_page(). This provides a way to update all get_user_pages*() callers, so that they call put_user_page(), instead of put_page(). Also introduces put_user_pages(), and a few dirty/locked variations, as a replacement

[PATCH 0/6] RFC v2: mm: gup/dma tracking

From: John Hubbard Hi, I'm calling this RFC v2, even though with all the discussion it actually feels like about v7 or so. But now that the dust has settled, it's time to show a surprisingly small, cleaner approach. Jan and Jerome came up with a scheme (discussed in more detail in "trac

[PATCH 4/6] mm/gup: track gup-pinned pages

From: John Hubbard Now that all callers of get_user_pages*() have been updated to use put_user_page(), instead of put_page(), add tracking of such "gup-pinned" pages. The purpose of this tracking is to answer the question "has this page been pinned by a call to get_user_page

[PATCH 6/6] mm/gup: Documentation/vm/get_user_pages.rst, MAINTAINERS

From: John Hubbard 1. Added Documentation/vm/get_user_pages.rst 2. Added a GET_USER_PAGES entry in MAINTAINERS Cc: Dan Williams Cc: Jan Kara Signed-off-by: Jérôme Glisse Signed-off-by: John Hubbard --- Documentation/vm/get_user_pages.rst | 197 Documentation

[PATCH 2/6] infiniband/mm: convert put_page() to put_user_page*()

From: John Hubbard For infiniband code that retains pages via get_user_pages*(), release those pages via the new put_user_page(), or put_user_pages*(), instead of put_page() This is a tiny part of the second step of fixing the problem described in [1]. The steps are: 1) Provide put_user_page

[PATCH 3/6] mm: page_cache_add_speculative(): refactoring

From: John Hubbard This combines the common elements of these routines: page_cache_get_speculative() page_cache_add_speculative() This was anticipated by the original author, as shown by the comment in commit ce0ad7f095258 ("powerpc/mm: Lockless get_user_pages_fast() for 64-bi

[PATCH 5/6] mm/gup: /proc/vmstat support for get/put user pages

From: John Hubbard Add five new /proc/vmstat items, to provide some visibility into what get_user_pages() and put_user_page() are doing. After booting and running fio (https://github.com/axboe/fio) a few times on an NVMe device, as a way to get lots of get_user_pages_fast() calls, the counters

Re: [PATCH 4/6] mm/gup: track gup-pinned pages

s. Therefore, only about 4M calls to get_user_page() may occur >> for >> + * a page. > > The refcount is 32-bit on both 64 and 32 bit systems. This limit > exists on both sizes of system. > Oh right, I'll just delete that last paragraph, then. Thanks for catching that. thanks, -- John Hubbard NVIDIA

Re: [PATCH 0/6] RFC v2: mm: gup/dma tracking

On 2/4/19 5:41 PM, Tom Talpey wrote: On 2/4/2019 12:21 AM, john.hubb...@gmail.com wrote: From: John Hubbard Performance: here is an fio run on an NVMe drive, using this for the fio configuration file: [reader] direct=1 ioengine=libaio blocksize=4096 size=1g

Re: [PATCH 6/6] mm/gup: Documentation/vm/get_user_pages.rst, MAINTAINERS

On 2/5/19 8:40 AM, Mike Rapoport wrote: > Hi John, > > On Sun, Feb 03, 2019 at 09:21:35PM -0800, john.hubb...@gmail.com wrote: >> From: John Hubbard >> >> 1. Added Documentation/vm/get_user_pages.rst >> >> 2. Added a GET_USER_PAGES entry in MAINTAINERS

Re: [PATCH 0/6] RFC v2: mm: gup/dma tracking

ciate your help here, as always! thanks, -- John Hubbard NVIDIA

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

On 2/8/19 2:32 AM, Mike Rapoport wrote: On Thu, Feb 07, 2019 at 11:56:48PM -0800, john.hubb...@gmail.com wrote: From: John Hubbard [...] +/** + * put_user_page() - release a gup-pinned page + * @page:pointer to page to be released + * + * Pages that were pinned via get_user_pages

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

do we just allow other kernel code to observe this biased _refcount, or do we attempt to filter it out? In other words, do you expect problems due to some kernel code checking the _refcount and finding a large number there, when it expected, say, 3? I recall some code tries to do that...in fact, ZONE_DEVICE is 1-based, instead of zero-based, with respect to _refcount, right? thanks, -- John Hubbard NVIDIA

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

bout actually attempting it, because remember that so far, each call site does no special tracking of each struct page. It just remembers that it needs to do a put_page(), not whether or not that particular page was set up with writeable or read-only GUP. I mean, sure, they often call set_page_dirty before put_page, indicating that it might have been a writeable GUP call, but it seems sketchy to rely on that. So actually doing this could go from merely lots of work, to K*(lots_of_work)... thanks, -- John Hubbard NVIDIA

<    4   5   6   7   8   9   10   11   12   13   >