On Wed, Aug 21, 2019 at 4:30 PM Thomas Hellström (VMware) thomas_os@shipmail.org wrote:
On 8/21/19 4:10 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware) thomas_os@shipmail.org wrote:
On 8/20/19 4:53 PM, Daniel Vetter wrote:
With nouveau fixed all ttm-using drives have the correct nesting of mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up anything with my audit of course.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com Cc: Christian Koenig christian.koenig@amd.com Cc: Huang Rui ray.huang@amd.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: "VMware Graphics" linux-graphics-maintainer@vmware.com Cc: Thomas Hellstrom thellstrom@vmware.com
drivers/gpu/drm/ttm/ttm_bo.c | 34 --------------------------------- drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------ include/drm/ttm/ttm_bo_api.h | 1 - 3 files changed, 1 insertion(+), 60 deletions(-)
dma_resv_lock(bo->base.resv, NULL);interruptible, or at least killable. (IIRC think killable is the right choice in fault code, even if TTM initially implemented interruptible to get reasonable Xorg "silken mouse" latency).
I think interruptible is fine. I chickend out of that for v1 because I always mix up the return code for _lock_interruptibl() :-)
:). IIRC I think the in-kernel users of fault() were unhappy with interruptible. (GUP?), but I guess it's better to use a bulk change at some point if necessary.
We've been using interruptible since forever, returning VM_FAULT_NOPAGE to get the signal handled and re-run. Seems to not have pissed off anyone thus far. I think if we do this I'll do it as a follow-up. -Daniel