similar to: [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

On Wed, Aug 21, 2019 at 11:50:29PM +0200, Daniel Vetter wrote: > We can't copy_*_user while holding reservations, that will (soon even > for nouveau) lead to deadlocks. And it breaks the cross-driver > contract around dma_resv. > > Fix this by adding a slowpath for when we need relocations, and by > pushing the writeback of the new presumed offsets to the very end. >

On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote: > We can't copy_*_user while holding reservations, that will (soon even > for nouveau) lead to deadlocks. And it breaks the cross-driver > contract around dma_resv. > > Fix this by adding a slowpath for when we need relocations, and by > pushing the writeback of the new presumed offsets to the very end. >

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

If ttm_bo_reserve() in nouveau_gem_pushbuf_validate() failed, the GEM object reference is leaked, since the object is not yet in the list for cleanup. Create a new function nouveau_gem_pushbuf_lookup_and_reserve() that does the GEM object lookup and ttm_bo_reserve() together, or fails and undos them both, eliminating GEM object reference leaks. I believe this bug lead to a permanent validation

Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 64e59fb..75cae79 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -595,7 +595,7 @@

Currently Nouveau will unvalidate all buffers if it is forced to wait on one, and then start revalidating from the beginning. While doing so, it destroys the operation fence, causing nouveau_fence_emit to crash. This patch fixes this bug by taking the fence object out of validate_op and creating it just before emit. The fence pointer is initialized to 0 and unref'ed unconditionally. In

On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > I was getting a order 4 allocation failure from kmalloc when testing some game > after a few days uptime with some suspend/resumes. For big allocations vmalloc > should be used instead. I've picked up this patch with a minor modification (see below) > > Also limit size more

This patch changes the pushbuffer ABI to: 1. No longer use/expose nouveau_pushbuffer. Everything is directly in nouveau_channel. This saves the extra "pushbuf" pointer dereference. 2. Use cur/end pointers instead of tracking the remaining size. Pushing data now only needs to alter cur and not both cur and remaining. The goal is to make the *_RING macros faster and make the

I was getting a order 4 allocation failure from kmalloc when testing some game after a few days uptime with some suspend/resumes. For big allocations vmalloc should be used instead. Also limit size more aggressively to 256 KiB. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 30 +++++++++++++++++++++++------- 1 file

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at vger.kernel.org #3.10+ --- drivers/gpu/drm/nouveau/nouveau_bo.c | 33

Am 15.04.23 um 04:02 schrieb John Ogness: > Commit 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait") > converted from ttm_bo_wait_ctx() to dma_resv_wait_timeout(). > However, dma_resv_wait_timeout() returns greater than zero on > success as opposed to ttm_bo_wait_ctx(). As a result, relocs > will fail and log errors even when it was a success. > > Change the

Commit 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait") converted from ttm_bo_wait_ctx() to dma_resv_wait_timeout(). However, dma_resv_wait_timeout() returns greater than zero on success as opposed to ttm_bo_wait_ctx(). As a result, relocs will fail and log errors even when it was a success. Change the return code handling to match that of nouveau_gem_ioctl_cpu_prep(), which was

Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included a logic-bug which results in the relocations not actually getting applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is never reached. This causes a regression with graphical corruption, triggered when relocations need to be done (for example after a suspend/resume cycle.) Fix by setting *apply_relocs

Date: Wed, 5 Apr 2023 18:38:54 +0200 The label ?out_prevalid? was used to jump to another pointer check despite of the detail in the implementation of the function ?nouveau_gem_ioctl_pushbuf? that it was determined already in one case that the corresponding variable contained an error pointer because of a failed call of the function ?u_memcpya?. Thus use an additional label. This issue was

From: Thierry Reding <treding at nvidia.com> Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be

From: Thierry Reding <treding at nvidia.com> Add a new nouveau_pushbuf_kick_fence() function that takes and emits a sync fence FD. The fence FD can be waited on, or merged with other fence FDs, or passed back to the kernel as a prerequisite for a subsequent HW operation. Based heavily on work by Lauri Peltonen <lpeltonen at nvidia.com> Signed-off-by: Thierry Reding <treding at

Use the newly added u64_to_user_pointer a bit more frequently. Signed-off-by: Joe Perches <joe at perches.com> --- drivers/gpu/drm/armada/armada_gem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++++--- drivers/gpu/drm/tegra/drm.c | 15 ++++++++------- drivers/gpu/drm/vc4/vc4_bo.c | 4 ++-- drivers/gpu/drm/vc4/vc4_gem.c | 10 +++++-----

Use the newly added u64_to_user_pointer a bit more frequently. Signed-off-by: Joe Perches <joe at perches.com> --- drivers/gpu/drm/armada/armada_gem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++++--- drivers/gpu/drm/tegra/drm.c | 15 ++++++++------- drivers/gpu/drm/vc4/vc4_bo.c | 4 ++-- drivers/gpu/drm/vc4/vc4_gem.c | 10 +++++-----