Re: [PATCH] drm/nouveau: Fixup gk20a instobj hierarchy

2023-12-14 Thread Dave Airlie
On Thu, 14 Dec 2023 at 19:26, Jon Hunter  wrote:
>
>
>
> On 08/12/2023 10:46, Thierry Reding wrote:
> > From: Thierry Reding 
> >
> > Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not
> > preserved across suspend") uses container_of() to cast from struct
> > nvkm_memory to struct nvkm_instobj, assuming that all instance objects
> > are derived from struct nvkm_instobj. For the gk20a family that's not
> > the case and they are derived from struct nvkm_memory instead. This
> > causes some subtle data corruption (nvkm_instobj.preserve ends up
> > mapping to gk20a_instobj.vaddr) that causes a NULL pointer dereference
> > in gk20a_instobj_acquire_iommu() (and possibly elsewhere) and also
> > prevents suspend/resume from working.
> >
> > Fix this by making struct gk20a_instobj derive from struct nvkm_instobj
> > instead.
> >
> > Fixes: 12c9b05da918 ("drm/nouveau/imem: support allocations not preserved 
> > across suspend")
> > Reported-by: Jonathan Hunter 
> > Signed-off-by: Thierry Reding 

I've applied this to drm-fixes.

Dave.


Re: [PATCH linux-next] drm/nouveau/disp: switch to use kmemdup() helper

2023-12-14 Thread Kees Cook
On Thu, Dec 14, 2023 at 08:03:22PM +0800, yang.gua...@zte.com.cn wrote:
> From: Yang Guang 
> 
> Use kmemdup() helper instead of open-coding to
> simplify the code.
> 
> Signed-off-by: Chen Haonan 

Sure, good cleanup.

Reviewed-by: Kees Cook 

-- 
Kees Cook


Re: [PATCH] drm/nouveau/kms/nv50-: Don't allow inheritance of headless iors

2023-12-14 Thread Borislav Petkov
On Wed, Dec 13, 2023 at 07:43:57PM -0500, Lyude Paul wrote:
> Turns out we made a silly mistake when coming up with OR inheritance on
> nouveau. On pre-DCB 4.1, iors are statically routed to output paths via the
> DCB. On later generations iors are only routed to an output path if they're
> actually being used. Unfortunately, it appears with NVIF_OUTP_INHERIT_V0 we
> make the mistake of assuming the later is true on all generations, which is
> currently leading us to return bogus ior -> head assignments through nvif,
> which causes WARN_ON().
> 
> So - fix this by verifying that we actually know that there's a head
> assigned to an ior before allowing it to be inherited through nvif. This
> -should- hopefully fix the WARN_ON on GT218 reported by Borislav.
> 
> Signed-off-by: Lyude Paul 
> Cc: Borislav Petkov 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
> index e4279f1772a1b..377d0e0cef848 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
> @@ -385,7 +385,7 @@ nvkm_uoutp_mthd_inherit(struct nvkm_outp *outp, void 
> *argv, u32 argc)
>  
>   /* Ensure an ior is hooked up to this outp already */
>   ior = outp->func->inherit(outp);
> - if (!ior)
> + if (!ior || !ior->arm.head)
>   return -ENODEV;
>  
>   /* With iors, there will be a separate output path for each type of 
> connector - and all of
> -- 

Thanks, that fixes it!

Reported-by: Borislav Petkov (AMD) 
Tested-by: Borislav Petkov (AMD) 

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette


Re: [PATCH] drm/nouveau: Fixup gk20a instobj hierarchy

2023-12-14 Thread Jon Hunter




On 08/12/2023 10:46, Thierry Reding wrote:

From: Thierry Reding 

Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not
preserved across suspend") uses container_of() to cast from struct
nvkm_memory to struct nvkm_instobj, assuming that all instance objects
are derived from struct nvkm_instobj. For the gk20a family that's not
the case and they are derived from struct nvkm_memory instead. This
causes some subtle data corruption (nvkm_instobj.preserve ends up
mapping to gk20a_instobj.vaddr) that causes a NULL pointer dereference
in gk20a_instobj_acquire_iommu() (and possibly elsewhere) and also
prevents suspend/resume from working.

Fix this by making struct gk20a_instobj derive from struct nvkm_instobj
instead.

Fixes: 12c9b05da918 ("drm/nouveau/imem: support allocations not preserved across 
suspend")
Reported-by: Jonathan Hunter 
Signed-off-by: Thierry Reding 
---
Note that this was probably subtly wrong before the above-mentioned
commit already, but I don't think we've seen any reports that would
indicate any actual failures related to this before. So I think it's
good enough to apply this fix for v6.7. The next closest thing would
be commit d8e83994aaf6 ("drm/nouveau/imem: improve management of
instance memory"), but that's 8 years old (Linux v4.3)...
---
  .../drm/nouveau/nvkm/subdev/instmem/gk20a.c| 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
index 1b811d6972a1..201022ae9214 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
@@ -49,14 +49,14 @@
  #include 
  
  struct gk20a_instobj {

-   struct nvkm_memory memory;
+   struct nvkm_instobj base;
struct nvkm_mm_node *mn;
struct gk20a_instmem *imem;
  
  	/* CPU mapping */

u32 *vaddr;
  };
-#define gk20a_instobj(p) container_of((p), struct gk20a_instobj, memory)
+#define gk20a_instobj(p) container_of((p), struct gk20a_instobj, base.memory)
  
  /*

   * Used for objects allocated using the DMA API
@@ -148,7 +148,7 @@ gk20a_instobj_iommu_recycle_vaddr(struct 
gk20a_instobj_iommu *obj)
list_del(>vaddr_node);
vunmap(obj->base.vaddr);
obj->base.vaddr = NULL;
-   imem->vaddr_use -= nvkm_memory_size(>base.memory);
+   imem->vaddr_use -= nvkm_memory_size(>base.base.memory);
nvkm_debug(>base.subdev, "vaddr used: %x/%x\n", imem->vaddr_use,
   imem->vaddr_max);
  }
@@ -283,7 +283,7 @@ gk20a_instobj_map(struct nvkm_memory *memory, u64 offset, 
struct nvkm_vmm *vmm,
  {
struct gk20a_instobj *node = gk20a_instobj(memory);
struct nvkm_vmm_map map = {
-   .memory = >memory,
+   .memory = >base.memory,
.offset = offset,
.mem = node->mn,
};
@@ -391,8 +391,8 @@ gk20a_instobj_ctor_dma(struct gk20a_instmem *imem, u32 
npages, u32 align,
return -ENOMEM;
*_node = >base;
  
-	nvkm_memory_ctor(_instobj_func_dma, >base.memory);

-   node->base.memory.ptrs = _instobj_ptrs;
+   nvkm_memory_ctor(_instobj_func_dma, >base.base.memory);
+   node->base.base.memory.ptrs = _instobj_ptrs;
  
  	node->base.vaddr = dma_alloc_attrs(dev, npages << PAGE_SHIFT,

   >handle, GFP_KERNEL,
@@ -438,8 +438,8 @@ gk20a_instobj_ctor_iommu(struct gk20a_instmem *imem, u32 
npages, u32 align,
*_node = >base;
node->dma_addrs = (void *)(node->pages + npages);
  
-	nvkm_memory_ctor(_instobj_func_iommu, >base.memory);

-   node->base.memory.ptrs = _instobj_ptrs;
+   nvkm_memory_ctor(_instobj_func_iommu, >base.base.memory);
+   node->base.base.memory.ptrs = _instobj_ptrs;
  
  	/* Allocate backing memory */

for (i = 0; i < npages; i++) {
@@ -533,7 +533,7 @@ gk20a_instobj_new(struct nvkm_instmem *base, u32 size, u32 
align, bool zero,
else
ret = gk20a_instobj_ctor_dma(imem, size >> PAGE_SHIFT,
 align, );
-   *pmemory = node ? >memory : NULL;
+   *pmemory = node ? >base.memory : NULL;
if (ret)
return ret;
  



Tested-by: Jon Hunter 

Thanks!
Jon

--
nvpublic