similar to: [PATCH] drm/nouveau: restore hw accelerated buffer copies

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #43 from Andreas Loew <awl1 at gmx.net> --- Hello again, so it looks like I have now tracked the issue down. The "offending" commit seems to be: 4c193d254ee94da02857b9670e815b1765a9579b (the first commit which showed the issue - I tried for more than half an hour with its direct predecessor

nv50_bo_move_m2mf might copy to tiled gart, in which case linear copy is not appropriate. --- drivers/gpu/drm/nouveau/nouveau_bo.c | 42 ++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 88f0c45..0daf3f0 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++

Seems to make suspend slightly more reliable on my system. Cc: stable at vger.kernel.org [3.7+] Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index b6bdc9f..5032c31 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -464,6

When `nouveau_dmem_copy_one` is called, the following error occurs: [272146.675156] nouveau 0000:06:00.0: fifo: PBDMA9: 00000004 [HCE_PRIV] ch 1 00000300 00003386 This indicates that a copy push command triggered a Host Copy Engine Privileged error on channel 1 (Copy Engine channel). To address this issue, modify the Copy Engine channel to allow privileged push commands Fixes: 6de125383a5cc

From: Yonatan Maman <Ymaman at Nvidia.com> When `nouveau_dmem_copy_one` is called, the following error occurs: [272146.675156] nouveau 0000:06:00.0: fifo: PBDMA9: 00000004 [HCE_PRIV] ch 1 00000300 00003386 This indicates that a copy push command triggered a Host Copy Engine Privileged error on channel 1 (Copy Engine channel). To address this issue, modify the Copy Engine channel to allow

Using the kernel global workqueue to signal fences can lead to unexpected deadlocks. Some other work (e.g. from a different driver) could directly or indirectly depend on this fence to be signaled. However, if the WQ_MAX_ACTIVE limit is reached by waiters, this can prevent the work signaling the fence from running. While this seems fairly unlikely, it's potentially exploitable. Fixes:

On Fri, Feb 23, 2024 at 10:14:53AM +1000, Dave Airlie wrote: > On Fri, 23 Feb 2024 at 00:45, Danilo Krummrich <dakr at redhat.com> wrote: > > > > Using the kernel global workqueue to signal fences can lead to > > unexpected deadlocks. Some other work (e.g. from a different driver) > > could directly or indirectly depend on this fence to be signaled. > >

Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau_drm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c index 65910e3..9eb90a6 100644 --- a/drm/nouveau_drm.c +++ b/drm/nouveau_drm.c @@ -562,21 +562,22 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime) NV_INFO(drm, "evicting

On 23/12/14 10:40, Vince Hsu wrote: > This patch adds some checks in the suspend/resume functions to distinguish > the dGPU and mobile GPU and exports some variables/functions so that the > nouveau platform device can reuse them. > Hi Vince, Afaiu one needs to export a symbol as it's used by another module or subsystem. With the follow up two patches you are not doing either one,

Not holding the mutex potentially causes corruption of the kernel channel when page flipping. Cc: stable at vger.kernel.org #3.13 Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 29c3efdfc7dd..76e3cf025c10 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c

From: Rodrigo Vivi <rodrigo.vivi at gmail.com> These are missed cases that I just identified with allyesconfig build. Fixes: 2966141ad2dd ("drm/ttm: rename ttm_mem_reg to ttm_resource.") Cc: Dave Airlie <airlied at redhat.com> Cc: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.h

If either idling channels or suspending the fence were to fail, the display would never be resumed. Also if a client fails, resume the fence (not functionally important, but it would potentially leak memory). See https://bugs.freedesktop.org/show_bug.cgi?id=70213 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Untested, but makes sense given that the bug report has cursor setting

The pointer used to walk the table of move ops and pick the right one for the current GPU was declared static, meaning its state was carried over between invocations of the function, and also made the function non-rentrant and thread-unsafe. Since the table is ordered such that newer GPU methods are listed first, the result of this was that initializing newer GPUs after older GPUs would result in

This patch series addresses two critical issues in the Nouveau driver related to device channels, error handling and memory leaking. - Memory Leak in migrate_to_ram - the migrate_to_ram function was identified as leaking memory when a copy push command fails. This results in the function returning a dirty HIGH_USER page, which can expose sensitive information and pose a security risk. To mitigate

On Mon, Jun 15, 2015 at 04:09:29PM +0900, Alexandre Courbot wrote: > From: Ari Hirvonen <ahirvonen at nvidia.com> > > Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling > mode for imported dma-bufs. This ioctl is staging for now > and enabled with the "staging_tiling" module option. > > Signed-off-by: Ari Hirvonen <ahirvonen at nvidia.com> >

From: Yonatan Maman <Ymaman at Nvidia.com> This patch series addresses two critical issues in the Nouveau driver related to device channels, error handling, and sensitive data leaks. - Vulnerability in migrate_to_ram: The migrate_to_ram function might return a dirty HIGH_USER page when a copy push command (FW channel) fails, potentially exposing sensitive data and posing a security

From: Yonatan Maman <Ymaman at Nvidia.com> This patch series addresses two critical issues in the Nouveau driver related to device channels, error handling, and sensitive data leaks. - Vulnerability in migrate_to_ram: The migrate_to_ram function might return a dirty HIGH_USER page when a copy push command (FW channel) fails, potentially exposing sensitive data and posing a security

On Sat, Sep 07, 2019 at 09:58:46PM -0400, Ilia Mirkin wrote: > On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding <thierry.reding at gmail.com> wrote: > > > > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote: > > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > > > > > Hi, > > > >

This adds some basic debug information about the internal nouveau state. making it slightly easier to determine which bo belongs to which vm address, as long as that program is still running. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/vm.h b/drivers/gpu/drm/nouveau/core/include/subdev/vm.h index

This patch adds some checks in the suspend/resume functions to distinguish the dGPU and mobile GPU and exports some variables/functions so that the nouveau platform device can reuse them. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/nouveau_drm.c | 16 +++++++++++----- drm/nouveau_drm.h | 2 ++ 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/drm/nouveau_drm.c