search for: _locked

Add virtio_gpu_queue_ctrl_buffer_nolock function, which does the same as virtio_gpu_queue_ctrl_buffer but does not take the virtqueue lock. The caller must hold the lock instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git

Add virtio_gpu_queue_ctrl_buffer_nolock function, which does the same as virtio_gpu_queue_ctrl_buffer but does not take the virtqueue lock. The caller must hold the lock instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git

...ffmann <kraxel at redhat.com> wrote: > > Add virtio_gpu_queue_ctrl_buffer_nolock function, which does the same as > > virtio_gpu_queue_ctrl_buffer but does not take the virtqueue lock. The > > caller must hold the lock instead. > > > The drm subsystem tends to use *_locked and *_unlocked suffixes. With > the latter being less common. > Not a big deal but perhaps you can use one of those for virtio ? _locked looks correct for this case to me (looking at drm_vm_close + drm_vm_close_locked to compare). I'll change it. cheers, Gerd

...lockdep_assert_held here for the ww_mutex. Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations we call the structure tracking the fences+lock the "reservation", but the naming scheme used is _lock/_unlock. I think would be good to be consistent with that, and use _locked here. Especially for a very simplified vram helper like this one I expect that's going to lead to less wtf moments by driver writers :-) Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align more with what we now have in dma-buf. Cheers, Daniel > + > + if (gbo->...

...lockdep_assert_held here for the ww_mutex. Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations we call the structure tracking the fences+lock the "reservation", but the naming scheme used is _lock/_unlock. I think would be good to be consistent with that, and use _locked here. Especially for a very simplified vram helper like this one I expect that's going to lead to less wtf moments by driver writers :-) Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align more with what we now have in dma-buf. Cheers, Daniel > + > + if (gbo->...

.... > > The other function is fence_is_signaled, which is used by code that is > interested in the fence state, together with fence_wait if it wants to > block and not just wants to know the momentary fence state. All the > other functions (the stuff that adds callbacks and the various _locked > and other versions) are just for fancy special cases. Well that's rather bad, cause IRQs aren't reliable enough on Radeon HW for such a thing. Especially on Prime systems and Macs. That's why we have this fancy HZ/2 timeout on all fence wait operations to manually check if the f...

...the ww_mutex. > > Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations > we call the structure tracking the fences+lock the "reservation", but the > naming scheme used is _lock/_unlock. > > I think would be good to be consistent with that, and use _locked here. > Especially for a very simplified vram helper like this one I expect that's > going to lead to less wtf moments by driver writers :-) > > Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align > more with what we now have in dma-buf. Given that mgag20...

...er 2015 at 12:42, Gerd Hoffmann <kraxel at redhat.com> wrote: > Add virtio_gpu_queue_ctrl_buffer_nolock function, which does the same as > virtio_gpu_queue_ctrl_buffer but does not take the virtqueue lock. The > caller must hold the lock instead. > The drm subsystem tends to use *_locked and *_unlocked suffixes. With the latter being less common. Not a big deal but perhaps you can use one of those for virtio ? Cheers, Emil

...The other function is fence_is_signaled, which is used by code that is >> interested in the fence state, together with fence_wait if it wants to >> block and not just wants to know the momentary fence state. All the >> other functions (the stuff that adds callbacks and the various _locked >> and other versions) are just for fancy special cases. > > Well that's rather bad, cause IRQs aren't reliable enough on Radeon HW for > such a thing. Especially on Prime systems and Macs. > > That's why we have this fancy HZ/2 timeout on all fence wait operations...

...>> Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations >> we call the structure tracking the fences+lock the "reservation", but the >> naming scheme used is _lock/_unlock. >> >> I think would be good to be consistent with that, and use _locked here. >> Especially for a very simplified vram helper like this one I expect that's >> going to lead to less wtf moments by driver writers :-) >> >> Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align >> more with what we now have in dma-buf....

Am 22.07.2014 17:42, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >> Drivers exporting fences need to provide a fence->signaled and a fence->wait >> function, everything else like fence->enable_signaling or calling >> fence_signaled() from the driver is optional. >> >> Drivers

...the ww_mutex. > > Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations > we call the structure tracking the fences+lock the "reservation", but the > naming scheme used is _lock/_unlock. > > I think would be good to be consistent with that, and use _locked here. > Especially for a very simplified vram helper like this one I expect that's > going to lead to less wtf moments by driver writers :-) > > Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align > more with what we now have in dma-buf. More aside: Coul...

...e turned on all the time. The other function is fence_is_signaled, which is used by code that is interested in the fence state, together with fence_wait if it wants to block and not just wants to know the momentary fence state. All the other functions (the stuff that adds callbacks and the various _locked and other versions) are just for fancy special cases. >> Locking >> correctness is enforced with some extremely nasty lockdep annotations >> + additional debugging infrastructure enabled with >> CONFIG_DEBUG_WW_MUTEX_SLOWPATH. We really need to be able to hold >> dma-...

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

This series adds new functions to the mmu interval notifier API to allow device drivers with MMUs to dynamically mirror a process' page tables based on device faults and invalidation callbacks. The Nouveau driver is updated to use the extended API and a set of stand alone self tests is added to help validate and maintain correctness. The patches are based on linux-5.5.0-rc6 and are for