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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx