Re: [PATCH 1/2] gpu: nova-core: add initial driver stub

ring), and an Ampere GPU, and traced through actually loading NovaCore, and it behaves as described above. thanks, -- John Hubbard

Re: [PATCH 1/2] gpu: nova-core: add initial driver stub

On 2/1/25 5:52 AM, Danilo Krummrich wrote: On Fri, Jan 31, 2025 at 08:01:00PM -0800, John Hubbard wrote: On 1/31/25 2:04 PM, Danilo Krummrich wrote: ... +/// Enum representation of the GPU generation. +#[derive(Debug)] +pub(crate) enum CardType { +/// Turing +TU100 = 0x160

Re: [PATCH 1/2] gpu: nova-core: add initial driver stub

onfig index 44c9ef1435a2..5df981920a94 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -39,6 +39,7 @@ source "drivers/gpu/vga/Kconfig" source "drivers/gpu/host1x/Kconfig" source "drivers/gpu/ipu-v3/Kconfig" +source "drivers/gpu/nova-core/Kconfig" source "drivers/gpu/drm/Kconfig" base-commit: 69b8923f5003664e3ffef102e7edfa2abdcf I'm always grateful when anyone uses "git format-patch --base", it makes life simpler. thanks, -- John Hubbard

Re: [PATCH v1 01/12] mm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs

d long gup_flags) if ((gup_flags & FOLL_LONGTERM) && vma_is_fsdax(vma)) return -EOPNOTSUPP; + if ((gup_flags & FOLL_SPLIT_PMD) && is_vm_hugetlb_page(vma)) + return -EOPNOTSUPP; + This seems correct by inspection, as one cannot split a h

Re: [RFC PATCH v1 00/10] mm: Introduce and use folio_owner_ops

hat support specific operations are accepted in foo(). (Rust at the language level looks a lot more like a replacement for C++, than a replacement for C, imho. By which I mean, it has lots of goodies for expressing things, built right into the language.) thanks, -- John Hubbard

Re: [PATCH net-next v16 12/13] selftests: add ncdevmem, netcat for devmem TCP

On 7/11/24 8:28 AM, Mina Almasry wrote: On Wed, Jul 10, 2024 at 5:44 PM John Hubbard wrote: On 7/9/24 5:17 PM, Mina Almasry wrote: ... diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile index bc3925200637c..39420a6e86b7f 100644 --- a/tools/testing

Re: [PATCH net-next v16 12/13] selftests: add ncdevmem, netcat for devmem TCP

.sh lib.sh net_helper.sh setup_loopback.sh setup_veth.sh @@ -104,6 +109,10 @@ TEST_INCLUDES := forwarding/lib.sh include ../lib.mk +# YNL build +YNL_GENS := netdev +include ynl.mk This seems to be missing a rule to generate ynl.mk, right? thanks, -- John Hubbard NVIDIA

Re: [PATCH v6] Documentation/gpu: VM_BIND locking document

using the same nomenclature as the drm-vm-bind-async.rst. Hi Thomas, As requested, for the pin_user_pages() aspects (the MMU notifier registration case), please feel free to add: Acked-by: John Hubbard v2: - s/gvm/gpu_vm/g (Rodrigo Vivi) - Clarify the userptr seqlock with a pointer to mm

Re: [PATCH v5 1/6] mm/gup: remove unused vmas parameter from get_user_pages()

completeness: s/mapcount/refcount/ :) whew, you had me going there! Now it all adds up. :) thanks, -- John Hubbard NVIDIA

Re: [PATCH mm-unstable v1 09/20] mm/gup: reliable R/O long-term pinning in COW mappings

include/linux/mm.h | 27 --- mm/gup.c | 10 +- mm/huge_memory.c | 2 +- mm/hugetlb.c | 7 --- 4 files changed, 34 insertions(+), 12 deletions(-) Looks good, Reviewed-by: John Hubbard thanks, -- John Hubbard NVIDIA diff -

Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

rned about, but it looks quite helpful here). And also, user space will need to open both /dev/dri/* and /dev/accel/* nodes, if it needs access to anything live objects that drivers/accel owns. thanks, -- John Hubbard NVIDIA

Re: [PATCH 6/7] nouveau/dmem: Evict device private memory during release

some point, we're going to make this all work with file-backed memory, which will *definitely* not be discardable--I realize that we're not there yet, of course. But here, it's reasonable to commit to just retrying indefinitely, really. Memory should eventually show up. And if it doesn't, then restarting the machine is better than corrupting data, generally. thanks, -- John Hubbard NVIDIA

Re: [PATCH v2 1/3] migrate.c: Remove vma check in migrate_vma_setup()

ring the comments into alignment with the code. * I don't think memset deals properly with a zero length input arg, so it's probably better to return 0, before that point. thanks, -- John Hubbard NVIDIA - if (args->start < args->vma->vm_start || - args->

Re: [PATCH v2 2/3] mm/gup.c: Migrate device coherent pages when pinning instead of failing

ith this: nr_foll_pin_acquired nr_foll_pin_released ...and those should normally be equal to each other when "at rest". I hope this is/was run, just to be sure? thanks, -- John Hubbard NVIDIA

Re: [PATCH v2 2/3] mm/gup.c: Migrate device coherent pages when pinning instead of failing

the many things to monitor, the FOLL_PIN counts in /proc/vmstat are especially helpful, whenever making changes to code that deals with this: nr_foll_pin_acquired nr_foll_pin_released ...and those should normally be equal to each other when "at rest".

Re: Phyr Starter

On 1/20/22 6:12 AM, Christoph Hellwig wrote: On Tue, Jan 11, 2022 at 12:17:18AM -0800, John Hubbard wrote: Zooming in on the pinning aspect for a moment: last time I attempted to convert O_DIRECT callers from gup to pup, I recall wanting very much to record, in each bio_vec, whether these pages

Re: Phyr Starter

And of course, you're signing for another huge naming debate with Linus if you go with the "cool" name here. :) thanks, -- John Hubbard NVIDIA

Re: [RFC] Make use of non-dynamic dmabuf in RDMA

;t need to worry so much about providing first-class support for non-ODP setups. I've got to drag my brain into 2021+! :) thanks, -- John Hubbard NVIDIA

Re: [RFC] Make use of non-dynamic dmabuf in RDMA

block migration from happening eg if the CPU touches it later or something. OK. I just want to avoid creating any API-level assumptions that dma_buf_pin() necessarily implies or requires migrating to host memory. thanks, -- John Hubbard NVIDIA

Re: [RFC] Make use of non-dynamic dmabuf in RDMA

ory in vidmem. So I think we don't want to rule out that behavior, right? Or is the thinking more like, "you're lucky that this old non-ODP setup works at all, and we'll make it work by routing through host/cpu memory, but it will be slow"? thanks, -- John Hubbard NVIDIA

Re: [PATCH v6 02/13] mm: remove extra ZONE_DEVICE struct page refcount

t we're here, if you drop this hunk then it will make merging easier, I think. [1] https://lore.kernel.org/r/20210813044133.1536842-4-jhubb...@nvidia.com thanks, -- John Hubbard NVIDIA

Re: [PATCH v9 07/10] mm: Device exclusive memory access

he the CPU, in that regard. My example was just one, out of a vast pool of possible behaviors. thanks, -- John Hubbard NVIDIA

Re: [PATCH v9 07/10] mm: Device exclusive memory access

, and only a tiny bit of (reduced!) data comes back to the CPU. In that case, freeing the physical page on the CPU is actually the best decision for the OS to make (if the OS is sufficiently prescient). thanks, -- John Hubbard NVIDIA

Re: [PATCH v9 07/10] mm: Device exclusive memory access

ose programming on devices that have GPU-like memory models. thanks, -- John Hubbard NVIDIA

Re: [PATCH v7 3/8] mm/rmap: Split try_to_munlock from try_to_unmap

On 3/30/21 8:56 PM, John Hubbard wrote: On 3/30/21 3:56 PM, Alistair Popple wrote: ... +1 for renaming "munlock*" items to "mlock*", where applicable. good grief. At least the situation was weird enough to prompt further investigation :) Renaming to mlock* doesn&#

Re: [PATCH v7 3/8] mm/rmap: Split try_to_munlock from try_to_unmap

as there is only one caller of try_to_munlock. - Alistair No objections here. :) thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 3/8] mm/rmap: Split try_to_munlock from try_to_unmap

unlock*" items to "mlock*", where applicable. good grief. Although, it seems reasonable to tack such renaming patches onto the tail end of this series. But whatever works. thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-dev

Re: [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr

ng in ^FOLL_LONGTERM ZONE_MOVEABLE before they're migrated) is still being worked on. So not big benefits yet. Yes. Great write-up, that's very clear, and it's exactly where we're at. Reviewed-by: John Hubbard thanks, -- John Hubbard NVIDIA Cc: John Hubbard Signed-

Re: [PATCH 0/9] Add support for SVM atomics in Nouveau

ut we can forcefully break this whenever we feel like by revoking the page, moving it, and then reinstating the gpu pte again and let it continue. Oh yes, that's true. If that's no possible then what we need here instead is an mlock() type of thing I think. No need for that, then.

Re: [PATCH 0/9] Add support for SVM atomics in Nouveau

asily write programs that do a long series of atomic operations. Such a program would be a little weird, but it's hard to rule out. - long term pin: the page cannot be moved, all migration must fail. Also this will have an impact on COW behaviour for fork (but not sure where those patches ar

Re: [PATCH v16 0/4] RDMA: Add dma-buf support

in, but not a refcount pin.) It's a nice clean design point that we need to preserve, and fortunately it doesn't conflict with anything I'm seeing here. But I want to say this out loud because I see some doubt about it creeping into the discussion. thanks, -- John Hubbard NVIDIA

Re: [PATCH rdma-core 2/3] pyverbs,tests: Cosmetic improvements for dma-buf allocation routines

Obviously not worth spinning another version for that, as it is still readable as-is. Just mentioning it for the sake of pointless perfectionism, and in case someone ever wonders why it was missed during a review. :) Either way, feel free to add: Reviewed-by: John Hubbard thanks, -- John Hubbard NV

Re: [PATCH v16 0/4] RDMA: Add dma-buf support

way to use this solution here for peer-to-peer. So I'm glad to see that so far you're not ruling out the pinning option. thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v16 0/4] RDMA: Add dma-buf support

about the future of pinning to vidmem, for this? It would allow a huge group of older GPUs and NICs and such to do p2p with this approach, and it seems like a natural next step, right? thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list

Re: [PATCH rdma-core v7 5/6] tests: Add tests for dma-buf based memory regions

dm_mr.close() + + +def check_dmabuf_support(unit=0): +""" +Check if dma-buf allocation is supported by the system. +Skip the test on failure. +""" +device_num = 128 + unit +try: +DmaBuf(1, unit=unit) unit?? Th

Re: [PATCH rdma-core 5/5] tests: Bug fix for get_access_flags()

spelling. "Coyyntext" just doesn't sound as good. :) :param num: Size of initial collection :return: A random legal value for MR flags """ thanks, -- John Hubbard NVIDIA ___ dri-devel

Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM

ly, and I'm not seeing a pud_mkhugespecial anywhere. So not sure this works, but probably just me missing something again. It means ioremap can't create an IO page PUD, it has to be broken up. Does ioremap even create anything larger than PTEs? From my reading, yes. See ioremap_try_hug

Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM

age, get_futex_key requires a * get_user_pages_fast_only implementation that can pin pages. Thus it's still * useful to have gup_huge_pmd even if we can't operate on ptes. */ thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dr

Re: [resource] 22b17dc667: Kernel panic - not syncing: Fatal exception

/O RESET_REG. To reproduce: git clone https://github.com/intel/lkp-tests.git cd lkp-tests bin/lkp install job.yaml # job file is attached in this email bin/lkp run job.yaml Thanks, oliver.s...@intel.com thanks, -- John Hubbard NVIDIA ___

Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM

On 11/1/20 2:30 AM, Daniel Vetter wrote: On Sun, Nov 1, 2020 at 6:22 AM John Hubbard wrote: On 10/31/20 7:45 AM, Daniel Vetter wrote: On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote: On 10/30/20 3:08 AM, Daniel Vetter wrote: ... By removing this check from this location, and changing

Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM

On 10/31/20 7:45 AM, Daniel Vetter wrote: On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote: On 10/30/20 3:08 AM, Daniel Vetter wrote: ... By removing this check from this location, and changing from pin_user_pages_locked() to pin_user_pages_fast(), I *think* we end up losing the check

Re: [PATCH v5 13/15] resource: Move devmem revoke code to resource framework

Cc: Jason Gunthorpe Cc: Kees Cook Cc: Dan Williams Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: Arnd Bergmann Cc:

Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM

below about this: (for vm_flags and vma_is_fsdax) we can also streamline the code a lot. Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Pawel Osciak Cc: Marek Szyprowski Cc: Kyungmin Park Cc: Tomasz Figa Cc: Mauro Carvalho Chehab Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Gliss

Re: [PATCH v5 0/5] RDMA: Add dma-buf support

ere to find the remaining patches: https://lore.kernel.org/dri-devel/1602799340-138152-1-git-send-email-jianxin.xi...@intel.com/ thanks, -- John Hubbard NVIDIA v5: * Fix a few warnings reported by kernel test robot: - no previous prototype for function 'ib_umem_dmabuf_release

Re: [PATCH v2 05/17] mm/frame-vector: Use FOLL_LONGTERM

less than ret == nr_frames. And the whole partially pinned region idea turns out to be just not useful for almost everyone, from what I recall of the gup/pup call sites. So I wonder if we should just have get_vaddr_frames do the cleanup here and return -EFAULT, if ret != nr_frames ? thanks, -- John H

Re: [PATCH v2 03/17] misc/habana: Stop using frame_vector helpers

On 10/9/20 12:59 AM, Daniel Vetter wrote: All we need are a pages array, pin_user_pages_fast can give us that directly. Plus this avoids the entire raw pfn side of get_vaddr_frames. Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc

Re: [PATCH v2 01/17] drm/exynos: Stop using frame_vector helpers

: Kyungmin Park Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-me...@vger.kernel.org -- v2: Use

Re: [PATCH RFC PKS/PMEM 57/58] nvdimm/pmem: Stray access protection for pmem->virt_addr

ds like a clumsy API design to *disable*, right?). And there is no hint about the scope. And it *could* be so much more readable like this: dev_access_enable(DEV_ACCESS_THIS_THREAD); thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list d

Re: [PATCH 1/4] mm: introduce vma_set_file function v2

On 10/9/20 12:33 AM, Christian König wrote: Am 08.10.20 um 23:49 schrieb John Hubbard: On 10/8/20 4:23 AM, Christian König wrote: ... diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index 3d69e51f3e4d..c9d5f1a38af3 100644 --- a/drivers/gpu/drm

Re: [PATCH 1/4] mm: introduce vma_set_file function v2

wrong, as it was already done within vma_set_file(). thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/13] mm: close race in generic_access_phys

something I'm sorta new to, so a newbie question: is it possible for the same pte to already be there, ever? If so, we be stuck in an infinite loop here. I'm sure that's not the case, but it's not yet obvious to me why it's impossible. Resource reservations maybe? thanks,

Re: [PATCH 06/13] media: videobuf2: Move frame_vector into media subsystem

horpe Cc: Pawel Osciak Cc: Marek Szyprowski Cc: Kyungmin Park Cc: Tomasz Figa Cc: Mauro Carvalho Chehab Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.o

Re: [PATCH 01/13] drm/exynos: Stop using frame_vector helpers

On 10/7/20 2:32 PM, Daniel Vetter wrote: On Wed, Oct 7, 2020 at 10:33 PM John Hubbard wrote: On 10/7/20 9:44 AM, Daniel Vetter wrote: ... @@ -398,15 +399,11 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d, dma_unmap_sgtable(to_dma_dev(g2d->drm_dev), g2d_userptr-&

Re: [PATCH 05/13] mm/frame-vector: Use FOLL_LONGTERM

pull the pup path out from the mmap_sem critical section as suggested by Jason. Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Pawel Osciak Cc: Marek Szyprowski Cc: Kyungmin Park Cc: Tomasz Figa Cc: Mauro Carvalho Chehab Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kar

Re: [PATCH 04/13] misc/habana: Use FOLL_LONGTERM for userptr

On 10/7/20 9:44 AM, Daniel Vetter wrote: These are persistent, not just for the duration of a dma operation. Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux...@kvack.org Cc: linux-arm-ker

Re: [PATCH 02/13] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists

: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-me...@vger.kernel.org --- drivers/gpu/drm/exynos

Re: [PATCH 03/13] misc/habana: Stop using frame_vector helpers

patch 1: you can further simplify by using unpin_user_pages_dirty_lock(). list_del(&userptr->job_node); thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/13] drm/exynos: Stop using frame_vector helpers

: Kyungmin Park Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-me...@vger.kernel.org --- drivers/gpu/drm/exynos

Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM

On 10/3/20 2:45 AM, Daniel Vetter wrote: On Sat, Oct 3, 2020 at 12:39 AM John Hubbard wrote: On 10/2/20 10:53 AM, Daniel Vetter wrote: For $reasons I've stumbled over this code and I'm not sure the change to the new gup functions in 55a650c35fea ("mm/gup: frame_vector: convert

Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM

think it's really good that you've brought this up. It's definitely time to add FOLL_LONGTERM wherever it's missing. thanks, -- John Hubbard NVIDIA There is already a dax specific check (added in b7f0554a56f2 ("mm: fail get_vaddr_frames() for filesystem-dax mappings"

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

On 8/25/20 1:32 AM, Jens Wiklander wrote: On Mon, Aug 24, 2020 at 02:11:25PM -0700, John Hubbard wrote: ... OK, one more try, this time actually handling the _USER_MAPPED vs. _KERNEL_MAPPED pages! thanks, John Hubbard NVIDIA Looks good and it works too! :-) I've tested it on my Hikey

[PATCH v3] tee: convert convert get_user_pages() --> pin_user_pages()

@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: John Hubbard --- OK, one more try, this time actually handling the _USER_MAPPED vs. _KERNEL_MAPPED pages! thanks, John Hubbard NVIDIA drivers/tee/tee_shm.c | 32 +++- 1 file

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

On 8/24/20 11:36 AM, 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.

[PATCH v2] tee: convert convert get_user_pages() --> pin_user_pages()

der Cc: Sumit Semwal Cc: tee-...@lists.linaro.org Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: John Hubbard --- OK, this should be indentical to v1 [1], but now rebased against Linux 5.9-rc2. As before, I've compile-tested it agai

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

On 2020-06-01 10:25, Andy Shevchenko wrote: On Mon, Jun 1, 2020 at 8:10 PM John Hubbard wrote: On 2020-06-01 03:35, Andy Shevchenko wrote: On Mon, Jun 1, 2020 at 1:00 AM John Hubbard wrote: On 2020-05-31 14:11, Andy Shevchenko wrote: ... JFYI, we have history.git starting from v0.01

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

On 2020-06-01 03:35, Andy Shevchenko wrote: On Mon, Jun 1, 2020 at 1:00 AM John Hubbard wrote: On 2020-05-31 14:11, Andy Shevchenko wrote: ... JFYI, we have history.git starting from v0.01. OK, thanks for that note. According to that history.git [1], then: drivers/video/pvr2fb.c had

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

part of commit 434502754f2 ("[PATCH] SH Merge") ...and that commit created the minor bug that patch 0001 here addresses. (+Cc Paul just for the sake of completeness.) [1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git thanks, -- John Hubb

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

On 2020-05-31 13:58, Sam Ravnborg wrote: ... Thanks, patches are now applied to drm-misc-next. They will hit -next soon, but you will have to wait until next (not the upcoming) merge window before they hit mainline linux. Sam Great! That will work out just fine. thanks, -- John

Re: [PATCH] drm/radeon: Convert get_user_pages() --> pin_user_pages()

x27;s time.) There were no *case 5* in the other patch posted in -mm. Do we need to add it ? Working on figuring that out [1], but it's not directly relevant to this thread. Maybe I shouldn't have brought it up here. :) [1] https://lore.kernel.org/r/20200529070343.gl14...@quack2.suse.cz

Re: [PATCH] drm/radeon: Convert get_user_pages() --> pin_user_pages()

On 2020-05-27 01:51, Daniel Vetter wrote: On Wed, May 27, 2020 at 10:48:52AM +0200, Daniel Vetter wrote: On Tue, May 26, 2020 at 03:57:45PM -0700, John Hubbard wrote: On 2020-05-26 14:00, Souptick Joarder wrote: This code was using get_user_pages(), in a "Case 2" scenario (DMA/RD

Re: [PATCH] drm/radeon: Convert get_user_pages() --> pin_user_pages()

t/Articles/807108/ Signed-off-by: Souptick Joarder Cc: John Hubbard Hi, I'm compile tested this, but unable to run-time test, so any testing help is much appriciated. --- drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/dri

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

ally, 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 Hubba

[PATCH v2] tee: convert get_user_pages() --> pin_user_pages()

der Cc: Sumit Semwal Cc: tee-...@lists.linaro.org Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: John Hubbard --- Hi, This fixes the typo ("convert convert") in the subject line, but otherwise no changes. thanks, John Hubb

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

On 2020-05-23 02:41, Chris Wilson wrote: Quoting John Hubbard (2020-05-22 06:19:27) The purpose of posting this series is to launch a test in the intel-gfx-ci tree. (The patches have already been merged into Andrew's linux-mm tree.) This applies to today's linux.git (note the base-

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

based on the latest linux-next (which has my changes now). Should be fine. And in fact it would be nice to get that done in this round, so that the pin* and get* APIs look the same. thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-

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

ally, 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

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

orm of 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 ind

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

we can ask Souptick 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-dupli

[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 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 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-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Signed-off-by: John Hubbard --- drivers/video

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

ergmann Cc: Daniel Vetter Cc: Gustavo A. R. Silva Cc: Jani Nikula Cc: dri-devel@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()

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

Cc: Arnd Bergmann Cc: Daniel Vetter Cc: Gustavo A. R. Silva Cc: Jani Nikula Cc: dri-devel@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/

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] 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 fo

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, beca

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 th

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

On 2020-05-18 22:18, 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.

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

der Cc: Sumit Semwal Cc: tee-...@lists.linaro.org Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: John Hubbard --- Note that I have only compile-tested this patch, although that does also include cross-compiling for a few other arches

[PATCH 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 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 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()

bool writeable arg. Also, if this series looks good, we can ask Souptick 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

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

ally, 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

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

orm of enabling interrupts was fragile at best. Signed-off-by: John Hubbard --- include/linux/mm.h | 1 + mm/gup.c | 60 ++ 2 files changed, 29 insertions(+), 32 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h ind

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

ally, 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 hmm v2 5/5] mm/hmm: remove the customizable pfn format from hmm_range_fault

N_VALID]; + return pmd_write(pmd) ? (HMM_PFN_VALID | HMM_PFN_WRITE) : HMM_PFN_VALID; I always found the previous range->flags[...] approach hard to remember, so it's nice to see a simpler version now. thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

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-by

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

>= are still 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)

Re: [PATCH hmm v2 1/5] mm/hmm: make CONFIG_DEVICE_PRIVATE into a select

On 2020-05-01 11:20, Jason Gunthorpe wrote: From: Jason Gunthorpe There is no reason for a user to select this or not directly - it should be selected by drivers that are going to use the feature, similar to how CONFIG_HMM_MIRROR works. Yes, this is a nice touch. Reviewed-by: John Hubbard

Re: [Nouveau] [PATCH] nouveau: no need to check return value of debugfs_create functions

On 2/13/20 2:39 PM, Greg Kroah-Hartman wrote: > On Thu, Feb 13, 2020 at 02:30:09PM -0800, John Hubbard wrote: >> On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote: >>> When calling debugfs functions, there is no need to ever check the >>> return value. The function can work

  1   2   3   4   5   6   7   >