similar to: [PATCH 1/1] drm/qxl: add mutex_lock/mutex_unlock to ensure the order in which resources are rele

On Sat, Apr 18, 2020 at 02:39:17PM +0800, Caicai wrote: > When a qxl resource is released, the list that needs to be released is > fetched from the linked list ring and cleared. When you empty the list, > instead of trying to determine whether the ttm buffer object for each > qxl in the list is locked, you release the qxl object and remove the > element from the list until the list

Lovely diffstat, thanks to the new generic fbdev emulation. drm/qxl/Makefile | 2 drm/qxl/qxl_draw.c | 232 ---------------------------------------- drm/qxl/qxl_drv.h | 21 --- drm/qxl/qxl_fb.c | 300 ----------------------------------------------------- Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 21 ---

On Wed, Apr 29, 2020 at 12:01:24PM +0300, Vasily Averin wrote: > qxl_release should not be accesses after qxl_push_*_ring_release() calls: > userspace driver can process submitted command quickly, move qxl_release > into release_ring, generate interrupt and trigger garbage collector. > > It can lead to crashes in qxl driver or trigger memory corruption > in some kmalloc-192 slab

On Fri, Mar 31, 2023 at 10:24?AM Tom Rix <trix at redhat.com> wrote: > > clang with W=1 reports > drivers/gpu/drm/qxl/qxl_ioctl.c:149:14: error: variable > 'num_relocs' set but not used [-Werror,-Wunused-but-set-variable] > int i, ret, num_relocs; > ^ > This variable is not used so remove it. > > Signed-off-by: Tom Rix <trix

Final driver! \o/ This is not a proper dma_fence because the hardware may never signal anything, so don't use dma-buf with qxl, ever. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/qxl/Makefile | 2 drivers/gpu/drm/qxl/qxl_cmd.c | 5 - drivers/gpu/drm/qxl/qxl_debugfs.c | 12 ++- drivers/gpu/drm/qxl/qxl_drv.h | 22 ++---

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +- drivers/gpu/drm/qxl/qxl_release.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c b/drivers/gpu/drm/qxl/qxl_debugfs.c index 013b938986c7..f30460782f05 100644 --- a/drivers/gpu/drm/qxl/qxl_debugfs.c +++

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +- drivers/gpu/drm/qxl/qxl_release.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c b/drivers/gpu/drm/qxl/qxl_debugfs.c index 013b938986c7..f30460782f05 100644 ---

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +- drivers/gpu/drm/qxl/qxl_release.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c b/drivers/gpu/drm/qxl/qxl_debugfs.c index bdb5ac0987ab..94439212a5c5 100644 ---

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +- drivers/gpu/drm/qxl/qxl_release.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c b/drivers/gpu/drm/qxl/qxl_debugfs.c index bdb5ac0987ab..94439212a5c5 100644 ---

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +- drivers/gpu/drm/qxl/qxl_release.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c b/drivers/gpu/drm/qxl/qxl_debugfs.c index bdb5ac0987ab..94439212a5c5 100644 ---

In ocfs2_remove_btree_range, when calling ocfs2_lock_refcount_tree and ocfs2_prepare_refcount_change_for_del failed, it goes to out and then tries to call mutex_unlock without mutex_lock before. And when calling ocfs2_reserve_blocks_for_rec_trunc failed, it should free ref_tree before return. Signed-off-by: Joseph Qi <joseph.qi at huawei.com> --- fs/ocfs2/alloc.c | 8 ++++---- 1 file

This reorders the list to keep track of what buffers are reserved, so previous members are always unreserved. This gets rid of some bookkeeping that's no longer needed, while simplifying the code some. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/qxl/qxl_release.c | 1 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 142

No users are left, kill it off! :D Conversion to the reservation api is next on the list, after that the functionality can be restored with rcu. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++------- drivers/gpu/drm/nouveau/nouveau_display.c | 6 -- drivers/gpu/drm/nouveau/nouveau_gem.c | 16 +-----

qxl expects that list_first_entry(release->bos) returns the first element qxl added to the list. ttm_eu_reserve_buffers() may reorder the list though. Add a release_bo field to struct qxl_release and use that instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 1 + drivers/gpu/drm/qxl/qxl_cmd.c | 6 ++----

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's hmm tree

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's hmm tree but this is >

On 6/14/19 10:39 AM, Ralph Campbell wrote: > On 6/13/19 5:49 PM, John Hubbard wrote: >> On 6/13/19 5:11 PM, Ralph Campbell wrote: ... >> Actually, the pre-existing code is a little concerning. Your change preserves >> the behavior, but it seems questionable to be doing a "return 0" (whether >> via the above break, or your change) when it's in this partially

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.885048] ------------------------------------- [ 1294.889773] test-malloc-vra/6299 is

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]

The qxl device supports only a single active framebuffer ("primary surface" in spice terminology). In multihead configurations are handled by defining rectangles within the primary surface for each head/crtc. Userspace which uses the qxl ioctl interface (xorg qxl driver) is aware of this limitation and will setup framebuffers and crtcs accordingly. Userspace which uses dumb