Am 06.02.23 um 19:21 schrieb Rob Clark:
On Mon, Feb 6, 2023 at 8:05 AM Christian König wrote:
Am 06.02.23 um 16:52 schrieb Rob Clark:
On Mon, Feb 6, 2023 at 2:15 AM Christian König wrote:
Am 03.02.23 um 19:10 schrieb Rob Clark:
From: Rob Clark
If userspace calls the AMDGPU_CS ioctl from m
On Mon, Feb 6, 2023 at 8:05 AM Christian König wrote:
>
> Am 06.02.23 um 16:52 schrieb Rob Clark:
> > On Mon, Feb 6, 2023 at 2:15 AM Christian König
> > wrote:
> >> Am 03.02.23 um 19:10 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
> >>> If userspace calls the AMDGPU_CS ioctl from multiple thr
Am 06.02.23 um 16:52 schrieb Rob Clark:
On Mon, Feb 6, 2023 at 2:15 AM Christian König wrote:
Am 03.02.23 um 19:10 schrieb Rob Clark:
From: Rob Clark
If userspace calls the AMDGPU_CS ioctl from multiple threads, because
the vm is global to the drm_file, you can end up with multiple threads
r
On Mon, Feb 6, 2023 at 2:15 AM Christian König wrote:
>
> Am 03.02.23 um 19:10 schrieb Rob Clark:
> > From: Rob Clark
> >
> > If userspace calls the AMDGPU_CS ioctl from multiple threads, because
> > the vm is global to the drm_file, you can end up with multiple threads
> > racing in amdgpu_vm_cl
Am 03.02.23 um 19:10 schrieb Rob Clark:
From: Rob Clark
If userspace calls the AMDGPU_CS ioctl from multiple threads, because
the vm is global to the drm_file, you can end up with multiple threads
racing in amdgpu_vm_clear_freed(). So the freed list should be
protected with the status_lock, si
From: Rob Clark
If userspace calls the AMDGPU_CS ioctl from multiple threads, because
the vm is global to the drm_file, you can end up with multiple threads
racing in amdgpu_vm_clear_freed(). So the freed list should be
protected with the status_lock, similar to other vm lists.
Fixes: d38ceaf99
