On 8/22/19 4:24 PM, Thomas Hellström (VMware) wrote:
On 8/22/19 4:02 PM, Koenig, Christian wrote:
Am 22.08.19 um 15:06 schrieb Daniel Vetter:
On Thu, Aug 22, 2019 at 07:56:56AM +0000, Koenig, Christian wrote:
Am 22.08.19 um 08:49 schrieb Daniel Vetter:
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.
v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use _lock_interruptible to be good citizens (Thomas)
Reviewed-by: Christian König <christian.koenig@xxxxxxx>
btw I realized I didn't remove your r-b, since v1 was broken.
For formality, can you pls reaffirm, or still something broken?
My r-b is still valid.
Only problem I see is that neither of us seems to have a good idea about
the different VM_FAULT_* replies.
I took a look in mm/gup.c. It seems like when using get_user_pages,
VM_FAULT_RETRY will retry
s/retry/return/
to a requesting caller telling it that a long wait was expected and
not performed, whereas VM_FAULT_NOPAGE will just keep get_user_pages
to spin. So the proposed patch should be correct from my understanding.
If the fault originates from user-space, I guess either is fine.
/Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
