[Intel-xe] [PATCH 1/5] drm/xe: Kill small race with userptr invalidation

Thomas Hellström thomas.hellstrom at linux.intel.com
Fri May 26 12:26:18 UTC 2023


Hi, Maarten,

On 5/26/23 14:10, Maarten Lankhorst wrote:
> Theoretically, we can hit a small race where we hit an invalidation
> after taking the lock in read-mode. In this case, take it in write
> mode instead.
>
> I don't think this is really an issue, but more of a robustness thing.

Invalidation can happen at any time up until we lock the 
userptr.notifier_lock for the final check before submission, so any 
racing invalidation would eventually get caught there.

Ofc we can do advisory checks like this along the way but most work we 
do in execbuf isn't wasted anyway, so we'll end up with extra code and 
we really should think through where we want those advisory checks and 
why in that case + update the commit message accordingly.

/Thomas



>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> ---
>   drivers/gpu/drm/xe/xe_exec.c | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_exec.c b/drivers/gpu/drm/xe/xe_exec.c
> index e44076ee2e11..187108c4be6d 100644
> --- a/drivers/gpu/drm/xe/xe_exec.c
> +++ b/drivers/gpu/drm/xe/xe_exec.c
> @@ -256,6 +256,13 @@ int xe_exec_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
>   		/* We don't allow execs while the VM is in error state */
>   		err = down_read_interruptible(&vm->lock);
>   		write_locked = false;
> +
> +		/* Userptr invalidation while we were still acquiring lock? */
> +		if (!err && !xe_vm_no_dma_fences(vm) && xe_vm_userptr_check_repin(vm)) {
> +			up_read(&vm->lock);
> +			err = down_write_killable(&vm->lock);
> +			write_locked = true;
> +		}
>   	}
>   	if (err)
>   		goto err_syncs;


More information about the Intel-xe mailing list