search for: type_vram

The value of struct drm_device.ttm.type_vram can become -1 for unknown types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds error when accessing struct nvif_mmu.type[]: [ 18.304116] ================================================================== [ 18.311649] BUG: KASAN: slab-out-of-bounds in nouveau_ttm_io_mem_...

....Gao at amd.com>; virtualization at lists.linux-foundation.org; spice- >> devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org >> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing >> MMU type >> >> The value of struct drm_device.ttm.type_vram can become -1 for unknown >> types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds >> error when accessing struct nvif_mmu.type[]: > > Would this make more sense to just set the type_vram = 0 instead of -1? >From what I understand, these indices refer to an...

...Likun Gao ><Likun.Gao at amd.com>; virtualization at lists.linux-foundation.org; spice- >devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org >Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing >MMU type > >The value of struct drm_device.ttm.type_vram can become -1 for unknown >types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds >error when accessing struct nvif_mmu.type[]: Would this make more sense to just set the type_vram = 0 instead of -1? Mike > > [ 18.304116] >=====================================...

...ndation.org; spice- > >>> devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org > >>> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when > >deferencing > >>> MMU type > >>> > >>> The value of struct drm_device.ttm.type_vram can become -1 for > >unknown > >>> types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds > >>> error when accessing struct nvif_mmu.type[]: > >> > >> Would this make more sense to just set the type_vram = 0 instead of -1? > >...

...tualization at lists.linux-foundation.org; spice- >>> devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org >>> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when >deferencing >>> MMU type >>> >>> The value of struct drm_device.ttm.type_vram can become -1 for >unknown >>> types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds >>> error when accessing struct nvif_mmu.type[]: >> >> Would this make more sense to just set the type_vram = 0 instead of -1? > >From what I understand, th...

...> >>> devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org >> >>> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when >> >deferencing >> >>> MMU type >> >>> >> >>> The value of struct drm_device.ttm.type_vram can become -1 for >> >unknown >> >>> types of memory (see nouveau_ttm_init()). This leads to an out-of- >bounds >> >>> error when accessing struct nvif_mmu.type[]: >> >> >> >> Would this make more sense to just set the type_vram = 0...

...* > diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h > index da8c46e09943..cd19c8ce5939 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h > @@ -158,6 +158,8 @@ struct nouveau_drm { > int type_vram; > int type_host[2]; > int type_ncoh[2]; > + struct mutex io_reserve_mutex; > + struct list_head io_reserve_lru; > } ttm; > > /* GEM interface support */ > diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c > inde...

...--git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h > index da8c46e09943..cd19c8ce5939 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h > @@ -158,6 +158,8 @@ struct nouveau_drm { > int type_vram; > int type_host[2]; > int type_ncoh[2]; > + struct mutex io_reserve_mutex; > + struct list_head io_reserve_lru; > } ttm; > > /* GEM interface support */ > diff --git a/drivers/gpu/drm/nouveau/nouvea...

Hi guys, I've already send this out in September last year, but only got a response from Daniel. Could you guys please test this and tell me what you think about it? Basically I'm trying to remove all driver specific features from TTM which don't need to be inside the framework. Thanks, Christian.

...*/ static inline void __iomem * diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index da8c46e09943..cd19c8ce5939 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -158,6 +158,8 @@ struct nouveau_drm { int type_vram; int type_host[2]; int type_ncoh[2]; + struct mutex io_reserve_mutex; + struct list_head io_reserve_lru; } ttm; /* GEM interface support */ diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 77a0c6ad3cef..50518b48e9b4 100644 --- a/drivers/...

...*/ static inline void __iomem * diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index f63ac72aa556..26a2c1090045 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -164,6 +164,8 @@ struct nouveau_drm { int type_vram; int type_host[2]; int type_ncoh[2]; + struct mutex io_reserve_mutex; + struct list_head io_reserve_lru; } ttm; /* GEM interface support */ diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 53c6f8827322..a62f37b1131c 100644 --- a/drivers/...

...* > diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h > index 70f34cacc552..060e2ab1fd95 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h > @@ -158,6 +158,8 @@ struct nouveau_drm { > int type_vram; > int type_host[2]; > int type_ncoh[2]; > + struct mutex io_reserve_mutex; > + struct list_head io_reserve_lru; > } ttm; > > /* GEM interface support */ > diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c > index f0d...

...*/ static inline void __iomem * diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index 70f34cacc552..060e2ab1fd95 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -158,6 +158,8 @@ struct nouveau_drm { int type_vram; int type_host[2]; int type_ncoh[2]; + struct mutex io_reserve_mutex; + struct list_head io_reserve_lru; } ttm; /* GEM interface support */ diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index f0daf958e03a..7f8495066e8b 100644 --- a/drivers/...

Hi guys, I already tried this a few month ago, but since I don't have NVidia hardware its rather hard to test for me (need to get some ordered). Dave brought up the topic that we should probably try to move the handling into Nouveau once more, so I tried to fix the problem Ben reported and rebased on top of current drm-misc-next. Dave can you test this? At least in theory the approach

Hi guys, so I got some hardware and tested this and after hammering out tons of typos it now seems to work fine. Could you give it more testing? Thanks in advance, Christian

Just a gentle ping on this. Already got the Acked-by from Daniel, but I need some of the nouveau guys to test this since I can only compile test it. Regards, Christian.

We are trying to remove the io_lru handling and depend on zero init base, offset and addr here. v2: init addr as well Signed-off-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index e3931e515906..772c640a6046 100644 ---

Hi guys, Well let's face it AGP is a total headache to maintain and dead for at least 10+ years. We have a lot of x86 specific stuff in the architecture independent graphics memory management to get the caching right, abusing the DMA API on multiple occasions, need to distinct between AGP and driver specific page tables etc etc... So the idea here is to just go ahead and remove the support