search for: dmem

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

The hmm_devmem_add() function doesn't return NULL, it returns error pointers. Fixes: 5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM") Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c inde...

...Cheers, Jérôme -------------- next part -------------- >From 0304725edbaa3b828598a3babb785e6b9555af0b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse at redhat.com> Date: Thu, 21 Mar 2019 13:08:46 -0400 Subject: [PATCH] gpu/nouveau: initialize some fields of dmem no matter what MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On GPU that do not support device memory we left dmem fields uninitialized and this lead to troube in suspend/resume which try to use those fields. It seems best to initialize those fields no m...

Fix call to nouveau_fence_emit() with wrong channel parameter. Fixes: 7f2a0b50b2b2 ("drm/nouveau: fence: separate fence alloc and emit") Signed-off-by: Danilo Krummrich <dakr at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c index 4ad40e42cae1..61e84562094a 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c @@ -678,7 +678,7 @@...

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 this while testing Jason Gunthorpe's hmm tree but this is independa...

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.8...

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] 5.2.0-rc3+ #5 Not tainted [ 1294.8...

...sing a security risk. To mitigate this, the patch ensures the allocation of a non-dirty (zero) page for the destination, preventing the return of a dirty page and enhancing driver security in case of failure. - Privileged Error in Copy Engine Channel: An error was observed when the nouveau_dmem_copy_one function is executed, leading to a Host Copy Engine Privileged error on channel 1. The patch resolves this by adjusting the Copy Engine channel configuration to permit privileged push commands, resolving the error. Changes since V3: - Fixed version according to Danilo Krummrich'...

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 this while testing Jason Gunthorpe...

...12: 0000000000000001 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000008 FS:  0000000000000000(0000) GS:ffff9dfe3ecc0000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 00000001a500e002 CR4: 00000000003606e0 Call Trace: nouveau_dmem_suspend (linux/drivers/gpu/drm/nouveau/nouveau_dmem.c:482 (discriminator 9)) nouveau nouveau_do_suspend (linux/drivers/gpu/drm/nouveau/nouveau_drm.c:748) nouveau nouveau_pmops_runtime_suspend (linux/drivers/gpu/drm/nouveau/nouveau_drm.c:915) nouveau pci_pm_runtime_suspend (linux/drivers/pci/pci-d...

...226,4 +409,1926 @@ gk20a_pmu_oclass = &(struct nvkm_pmu_impl) { > .init = gk20a_pmu_init, > .fini = gk20a_pmu_fini, > }, > + .base.handle = NV_SUBDEV(PMU, 0xea), > + .pgob = gk20a_pmu_pgob, > }.base; > +void pmu_copy_from_dmem(struct pmu_desc *pmu, > + u32 src, u8 *dst, u32 size, u8 port) > +{ > + u32 i, words, bytes; > + u32 data, addr_mask; > + u32 *dst_u32 = (u32 *)dst; > + struct nvkm_pmu *ppmu = (void *)nvkm_pmu((void *) > + impl_from_pmu(pmu))...

...app_ver_err: + gk20a_pmu_release_firmware(ppmu, pmufw); return ret; } @@ -226,4 +409,1926 @@ gk20a_pmu_oclass = &(struct nvkm_pmu_impl) { .init = gk20a_pmu_init, .fini = gk20a_pmu_fini, }, + .base.handle = NV_SUBDEV(PMU, 0xea), + .pgob = gk20a_pmu_pgob, }.base; +void pmu_copy_from_dmem(struct pmu_desc *pmu, + u32 src, u8 *dst, u32 size, u8 port) +{ + u32 i, words, bytes; + u32 data, addr_mask; + u32 *dst_u32 = (u32 *)dst; + struct nvkm_pmu *ppmu = (void *)nvkm_pmu((void *) + impl_from_pmu(pmu)); + + if (size == 0) { + nv_error(ppmu, "size is zero\n"); + goto out; +...

...sing a security risk. To mitigate this, the patch ensures the allocation of a non-dirty (zero) page for the destination, preventing the return of a dirty page and enhancing driver security in case of failure. - Privileged Error in Copy Engine Channel: An error was observed when the nouveau_dmem_copy_one function is executed, leading to a Host Copy Engine Privileged error on channel 1. The patch resolves this by adjusting the Copy Engine channel configuration to permit privileged push commands, resolving the error. Changes since V2: - Fixed version according to Danilo Krummrich'...

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 this while...

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 add...

...226,4 +409,1926 @@ gk20a_pmu_oclass = &(struct nvkm_pmu_impl) { > .init = gk20a_pmu_init, > .fini = gk20a_pmu_fini, > }, > + .base.handle = NV_SUBDEV(PMU, 0xea), > + .pgob = gk20a_pmu_pgob, > }.base; > +void pmu_copy_from_dmem(struct pmu_desc *pmu, > + u32 src, u8 *dst, u32 size, u8 port) > +{ > + u32 i, words, bytes; > + u32 data, addr_mask; > + u32 *dst_u32 = (u32 *)dst; > + struct nvkm_pmu *ppmu = (void *)nvkm_pmu((void *) > + impl_from_pmu(pmu))...

On Thu, Jun 13, 2019 at 05:11:21PM -0700, 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 this while testing Jason Gunthorpe...

...it only allocates part of what was requested, >> and it doesn't fill in the pages array either. >> >> >> >>> +                    return 0; >>>                   return ret; >>>               } >>> +            mutex_lock(&drm->dmem->mutex); >>>               continue; >>>           } >>>   >> >> The above comment is about pre-existing potential problems, but your patch itself >> looks correct, so: >> >> Reviewed-by: John Hubbard <jhubbard at nvidia.com> >&gt...

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 mapp...

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