search for: struct_mutex

============================================= [ INFO: possible recursive locking detected ] 3.17.0 #50 Not tainted --------------------------------------------- Xorg/1170 is trying to acquire lock: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa010ae93>] i915_gem_unmap_dma_buf+0x33/0xc0 [i915] but task is already holding lock: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa001cd1a>] drm_gem_object_handle_unreference_unlocked+0xca/0x120 [drm] other info that might help us debug this: Possible u...

...k is an Intel i5-460M. Kind regards, Peter dmesg: ============================================= [ INFO: possible recursive locking detected ] 3.15.0-rc8-custom-00058-gd2cfd31 #1 Tainted: G O --------------------------------------------- X/25827 is trying to acquire lock: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa008ebb6>] i915_gem_unmap_dma_buf+0x36/0xd0 [i915] but task is already holding lock: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa00055c5>] drm_gem_object_handle_unreference_unlocked+0x105/0x130 [drm] other info that might help us debug this: Possible...

...Oct 13, 2014 at 08:40:33PM +0200, Marcin ?lusarz wrote: > ============================================= > [ INFO: possible recursive locking detected ] > 3.17.0 #50 Not tainted > --------------------------------------------- > Xorg/1170 is trying to acquire lock: > (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa010ae93>] i915_gem_unmap_dma_buf+0x33/0xc0 [i915] > > but task is already holding lock: > (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa001cd1a>] drm_gem_object_handle_unreference_unlocked+0xca/0x120 [drm] > > other info that might help u...

...oid __user *)arg, kdata, usize) != 0) diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c index aa454f8..4af3227 100644 --- a/drivers/gpu/drm/drm_stub.c +++ b/drivers/gpu/drm/drm_stub.c @@ -275,6 +275,8 @@ int drm_fill_in_dev(struct drm_device *dev, mutex_init(&dev->struct_mutex); mutex_init(&dev->ctxlist_mutex); + init_rwsem(&dev->ioctls_rwsem); + if (drm_ht_create(&dev->map_hash, 12)) { return -ENOMEM; } diff --git a/include/drm/drmP.h b/include/drm/drmP.h index dd73104..527dca5 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -...

...nouveau_bo_pin(nvbo, domain_to_ttm(nvbo, req->domain)); - if (ret) - goto out; - - req->offset = nvbo->bo.offset; - if (nvbo->bo.mem.mem_type == TTM_PL_TT) - req->domain = NOUVEAU_GEM_DOMAIN_GART; - else - req->domain = NOUVEAU_GEM_DOMAIN_VRAM; - -out: - mutex_lock(&dev->struct_mutex); - drm_gem_object_unreference(gem); - mutex_unlock(&dev->struct_mutex); - - return ret; -} - -int -nouveau_gem_ioctl_unpin(struct drm_device *dev, void *data, - struct drm_file *file_priv) -{ - struct drm_nouveau_gem_pin *req = data; - struct drm_gem_object *gem; - int ret; - - NOUVEAU_CH...

...rivers/gpu/drm/nouveau/nouveau_state.c index 09b9a46..c212742 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -525,6 +525,7 @@ static void nouveau_card_takedown(struct drm_device *dev) engine->mc.takedown(dev); mutex_lock(&dev->struct_mutex); + ttm_bo_clean_mm(&dev_priv->ttm.bdev, TTM_PL_VRAM); ttm_bo_clean_mm(&dev_priv->ttm.bdev, TTM_PL_TT); mutex_unlock(&dev->struct_mutex); nouveau_sgdma_takedown(dev); -- 1.6.3.3

...words; i++) NV_ERROR(dev, "0x%08x\n", pushbuf[i]); @@ -614,7 +605,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, } out: - validate_fini(&op, ret == 0); + validate_fini(&op, fence); + nouveau_fence_unref((void**)&fence); mutex_unlock(&dev->struct_mutex); kfree(pushbuf); kfree(bo); @@ -634,6 +626,7 @@ nouveau_gem_ioctl_pushbuf_call(struct drm_device *dev, void *data, struct drm_gem_object *gem; struct nouveau_bo *pbbo; struct validate_op op; + struct nouveau_fence* fence = 0; int i, ret = 0, do_reloc = 0; NOUVEAU_CHECK_INITIALISED_...

...ll fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place? >>> Agreed that any shared locks are out of the way (especially stuff like >>> dev->struct_mutex or other non-strictly driver-private stuff, i915 is >>> really bad here still). >> Yeah that's also an point I've wanted to note on Maartens patch. Radeon grabs the read side of it's exclusive semaphore while waiting for fences (because it assumes that the fence it waits...

...the current assigned fence at some point is signaled? Something like grab ww_mutexes, grab a reference to the current fence object, release ww_mutex, wait for fence, release reference to the fence object. > Agreed that any shared locks are out of the way (especially stuff like > dev->struct_mutex or other non-strictly driver-private stuff, i915 is > really bad here still). Yeah that's also an point I've wanted to note on Maartens patch. Radeon grabs the read side of it's exclusive semaphore while waiting for fences (because it assumes that the fence it waits for is a Radeo...

...nabled with CONFIG_DEBUG_WW_MUTEX_SLOWPATH. We really need to be able to hold dma-buf ww_mutexes while updating fences or waiting for them. And obviously for ->wait we need non-atomic context, not just non-interrupt. Agreed that any shared locks are out of the way (especially stuff like dev->struct_mutex or other non-strictly driver-private stuff, i915 is really bad here still). So from the core fence framework I think we already have exactly this, and we only need to adjust the radeon implementation a bit to make it less risky and invasive to the radeon driver logic. -Daniel -- Daniel Vetter Sof...

..._mode_config_funcs = { diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index ecbfe69..839b7e7 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -385,6 +385,7 @@ out_unlock: mutex_unlock(&dev->struct_mutex); if (chan) nouveau_bo_vma_del(nvbo, &fbcon->nouveau_fb.vma); + nouveau_bo_unmap(nvbo); out_unpin: nouveau_bo_unpin(nvbo); out_unref: @@ -415,6 +416,12 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) } if (nouveau_fb->nvbo) { + struct drm_crtc...

...ev_priv) < 9) > state->legacy_cursor_update = false; > > - drm_atomic_helper_swap_state(state, true); > + ret = drm_atomic_helper_swap_state(state, true); > + if (ret) { > + i915_sw_fence_commit(&intel_state->commit_ready); > + > + mutex_lock(&dev->struct_mutex); > + drm_atomic_helper_cleanup_planes(dev, state); > + mutex_unlock(&dev->struct_mutex); > + return ret; > + } > dev_priv->wm.distrust_bios_wm = false; > intel_shared_dpll_swap_state(state); > intel_atomic_track_fbs(state); lgtm. > diff --git a/drivers/...

...+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -595,7 +595,7 @@ nouveau_gem_ioctl_pushbuf_call(struct drm_device *dev, void *data, bo = u_memcpya(req->buffers, req->nr_buffers, sizeof(*bo)); if (IS_ERR(bo)) - return (unsigned long)bo; + return PTR_ERR(bo); mutex_lock(&dev->struct_mutex); @@ -622,7 +622,7 @@ nouveau_gem_ioctl_pushbuf_call(struct drm_device *dev, void *data, ret = -EINVAL; goto out; } - pbbo = gem->driver_private; + pbbo = nouveau_gem_object(gem); ret = ttm_bo_reserve(&pbbo->bo, false, false, true, chan->fence.sequence); @@ -669,...

...ure. Mathias Tillman (1): drm: fix the usage after free Mauro Rossi (2): amdgpu: add Makefile.sources amdgpu: add Android build support Michel Dänzer (1): tests: Add -lm to LDADD for dristat Rafał Sapała (1): intel: Serialize drmPrimeFDToHandle with struct_mutex Rob Clark (4): freedreno: don't take ownership of the dmabuf fd on import drm: make individual drm_server_info fxns optional freedreno: add API to get drm fd from fd_device Bump version for release Thierry Reding (1): omap: Initialize DMA BUF file descrip...

...It doesn't need to be completely reliable, or finish immediately. And any time wake_up_all(&rdev->fence_queue) is called all the fences that were enabled will be rechecked. >>>> Agreed that any shared locks are out of the way (especially stuff like >>>> dev->struct_mutex or other non-strictly driver-private stuff, i915 is >>>> really bad here still). >>> Yeah that's also an point I've wanted to note on Maartens patch. Radeon grabs the read side of it's exclusive semaphore while waiting for fences (because it assumes that the fence i...

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

...dex ab9d7bee0aae..7b21e4135aa5 100644 > --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c > +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c > @@ -490,7 +490,7 @@ int i915_gem_evict_mock_selftests(void) > err = i915_subtests(tests, i915); > mutex_unlock(&i915->drm.struct_mutex); > > - drm_dev_unref(&i915->drm); > + drm_dev_put(&i915->drm); > return err; > } > > diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c > index f7dc926f4ef1..1cf4e9af0b65 100644 > --- a/drivers/...

...tests/i915_gem_evict.c index ab9d7bee0aae..7b21e4135aa5 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c @@ -490,7 +490,7 @@ int i915_gem_evict_mock_selftests(void) err = i915_subtests(tests, i915); mutex_unlock(&i915->drm.struct_mutex); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index f7dc926f4ef1..1cf4e9af0b65 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/d...

...tests/i915_gem_evict.c index ab9d7bee0aae..7b21e4135aa5 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c @@ -490,7 +490,7 @@ int i915_gem_evict_mock_selftests(void) err = i915_subtests(tests, i915); mutex_unlock(&i915->drm.struct_mutex); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index f7dc926f4ef1..1cf4e9af0b65 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/d...

...tests/i915_gem_evict.c index ab9d7bee0aae..7b21e4135aa5 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c @@ -490,7 +490,7 @@ int i915_gem_evict_mock_selftests(void) err = i915_subtests(tests, i915); mutex_unlock(&i915->drm.struct_mutex); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index f7dc926f4ef1..1cf4e9af0b65 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/d...