On Wed, Aug 21, 2019 at 4:30 PM Thomas Hellström (VMware) <thomas_os@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxx> > >>> Cc: Christian Koenig <christian.koenig@xxxxxxx> > >>> Cc: Huang Rui <ray.huang@xxxxxxx> > >>> Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx> > >>> Cc: "VMware Graphics" <linux-graphics-maintainer@xxxxxxxxxx> > >>> Cc: Thomas Hellstrom <thellstrom@xxxxxxxxxx> > >>> --- > >>> 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
