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

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

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

Factor the main copy page to ram routine out into a helper that acts on a single page and which doesn't require the nouveau_dmem_fault structure for argument passing. Also remove the loop over multiple pages as we only handle one at the moment, although the structure of the main worker function makes it relatively easy to add multi page support back if needed in the future. But at least for now this avoid the needed to dyn...

Factor the main copy page to ram routine out into a helper that acts on a single page and which doesn't require the nouveau_dmem_fault structure for argument passing. Also remove the loop over multiple pages as we only handle one at the moment, although the structure of the main worker function makes it relatively easy to add multi page support back if needed in the future. But at least for now this avoid the needed to dyn...