weird reservation issues

[Christian König]

Hi Monk,

yeah thinking about those issue currently as well. It indeed looks like 
we have some kind of race here.

When we call backoff_reservation the next iteration of the look will 
reserve all BOs again, so that can't be the issue.

Regards,
Christian.

Am 28.02.2018 um 11:37 schrieb Liu, Monk:
>
> Hi Christian
>
> In amdgpu_cs_parser_bos(), it calls ttm_eu_backoff_reservation() if 
> @need_pages not empty, is it safe ?
>
> You see that if two threads in parallel running in cs_parser_bos(), if 
> the thread1 did call backoff_reservation and continue, that leaves
>
> All following reservation functions on root BO executed without 
> protection from the lock, Meanwhile if this time thread2 call 
> cs_parser_bos() in parallel, it can
>
> Get the lock of the reservation object on root BO (assume thread 1/2 
> share the same VM) immediately, so both of those threads consider they 
> are
>
> Under protection of lock of reservation on the root bo. Do you think 
> it’s a race issue ?
>
> You know that I recently hit BUG() in reservation.c, and also found 
> some weird bugs can be fixed by removing the kfree(obj->staged)
>
> In reservation_object_reserve_shared(), and I think you right on the 
> “staged” part that it shouldn’t be freed if everything go with rules (
>
> Always held the lock of the bo)
>
> Thanks
>
> /Monk
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180228/29e7301b/attachment-0001.html>