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>
