similar to: [PATCH] nouveau: fix incorrect sizeof on args.src an args.dst

From: Colin Ian King <colin.king at canonical.com> [ Upstream commit f42e4b337b327b1336c978c4b5174990a25f68a0 ] The sizeof is currently on args.src and args.dst and should be on *args.src and *args.dst. Fortunately these sizes just so happen to be the same size so it worked, however, this should be fixed and it also cleans up static analysis warnings Addresses-Coverity: ("sizeof not

From: Colin Ian King <colin.king at canonical.com> [ Upstream commit f42e4b337b327b1336c978c4b5174990a25f68a0 ] The sizeof is currently on args.src and args.dst and should be on *args.src and *args.dst. Fortunately these sizes just so happen to be the same size so it worked, however, this should be fixed and it also cleans up static analysis warnings Addresses-Coverity: ("sizeof not

Factor the main copy page to vram routine out into a helper that acts on a single page and which doesn't require the nouveau_dmem_migrate structure for argument passing. As an added benefit the new version only allocates the dma address array once and reuses it for each subsequent chunk of work. Signed-off-by: Christoph Hellwig <hch at lst.de> ---

When memory is migrated to the GPU, it is likely to be accessed by GPU code soon afterwards. Instead of waiting for a GPU fault, map the migrated memory into the GPU page tables with the same access permissions as the source CPU page table entries. This preserves copy on write semantics. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> Cc: Christoph Hellwig <hch at lst.de> Cc:

On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote: > When memory is migrated to the GPU it is likely to be accessed by GPU > code soon afterwards. Instead of waiting for a GPU fault, map the > migrated memory into the GPU page tables with the same access permissions > as the source CPU page table entries. This preserves copy on write > semantics. > >

Add a new opaque owner field to struct dev_pagemap, which will allow the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory, and refuse to work on mappings not owned by the calling entity. Signed-off-by: Christoph Hellwig <hch at lst.de> --- arch/powerpc/kvm/book3s_hv_uvmem.c | 4 ++++ drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +++ include/linux/memremap.h

The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to

There isn't any good reason to pass callbacks to migrate_vma. Instead we can just export the three steps done by this function to drivers and let them sequence the operation without callbacks. This removes a lot of boilerplate code as-is, and will allow the drivers to drastically improve code flow and error handling further on. Signed-off-by: Christoph Hellwig <hch at lst.de> ---

There isn't any good reason to pass callbacks to migrate_vma. Instead we can just export the three steps done by this function to drivers and let them sequence the operation without callbacks. This removes a lot of boilerplate code as-is, and will allow the drivers to drastically improve code flow and error handling further on. Signed-off-by: Christoph Hellwig <hch at lst.de>

On 3/6/24 06:01, Duoming Zhou wrote: > The kcalloc() in nouveau_dmem_evict_chunk() will return null if > the physical memory has run out. As a result, if we dereference > src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs > will happen. > > Moreover, the GPU is going away. If the kcalloc() fails, we could not > evict all pages mapping a chunk. So this patch

On 7/29/19 7:28 AM, Christoph Hellwig wrote: > There isn't any good reason to pass callbacks to migrate_vma. Instead > we can just export the three steps done by this function to drivers and > let them sequence the operation without callbacks. This removes a lot > of boilerplate code as-is, and will allow the drivers to drastically > improve code flow and error handling

The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. This patch uses stack variables to replace the kcalloc(). Fixes: 249881232e14 ("nouveau/dmem: evict device private memory during release") Signed-off-by: Duoming Zhou <duoming

No one ever checks this flag, and we could easily get that information from the page if needed. Signed-off-by: Christoph Hellwig <hch at lst.de> Reviewed-by: Ralph Campbell <rcampbell at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +-- include/linux/migrate.h | 1 - mm/migrate.c | 4 ++-- 3 files changed, 3 insertions(+), 5

No driver has actually used properly wire up and support this feature. There is various code related to it in nouveau, but as far as I can tell it never actually got turned on, and the only changes since the initial commit are global cleanups. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 - drivers/gpu/drm/nouveau/nouveau_dmem.c | 37

In nouveau_dmem_init(), a number of struct nouveau_dmem_chunk are allocated and put on the dmem->chunk_empty list. Then in nouveau_dmem_pages_alloc(), a nouveau_dmem_chunk is removed from the list and GPU memory is allocated. However, the nouveau_dmem_chunk is never removed from the chunk_empty list nor placed on the chunk_free or chunk_full lists. This results in only one chunk ever being

In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before calling nouveau_dmem_chunk_alloc() as shown when CONFIG_PROVE_LOCKING is enabled: [ 1294.871933] ===================================== [ 1294.876656] WARNING: bad unlock balance detected! [ 1294.881375] 5.2.0-rc3+ #5 Not tainted [ 1294.885048] ------------------------------------- [ 1294.889773] test-malloc-vra/6299 is

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit d304654bd79332ace9ac46b9a3d8de60acb15da3 ] In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before calling nouveau_dmem_chunk_alloc() as shown when CONFIG_PROVE_LOCKING is enabled: [ 1294.871933] ===================================== [ 1294.876656] WARNING: bad unlock balance detected! [ 1294.881375]

When memory is migrated to the GPU it is likely to be accessed by GPU code soon afterwards. Instead of waiting for a GPU fault, map the migrated memory into the GPU page tables with the same access permissions as the source CPU page table entries. This preserves copy on write semantics. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> Cc: Christoph Hellwig <hch at lst.de> Cc:

On 2020-06-22 16:38, Ralph Campbell wrote: > The OpenCL function clEnqueueSVMMigrateMem(), without any flags, will > migrate memory in the given address range to device private memory. The > source pages might already have been migrated to device private memory. > In that case, the source struct page is not checked to see if it is > a device private page and incorrectly computes the

On 6/13/19 5:49 PM, John Hubbard wrote: > On 6/13/19 5:11 PM, Ralph Campbell wrote: >> In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before >> calling nouveau_dmem_chunk_alloc(). >> Reacquire the lock before continuing to the next page. >> >> Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> >> --- >> >> I found