ttm_bo_move_sync_cleanup() issue

ttm_bo_move_sync_cleanup() issue

[Matthew Auld]

Hi Christian,

We seem to be hitting a new issue in ttm_bo_move_sync_cleanup(), due
to passing a NULL fence, and I guess with some recent changes this is
now blowing up in at least dma_resv_add_fence(). Question is how
should we handle this? Should we add a special case in
ttm_bo_move_accel_cleanup() in case of NULL fence, and then maybe just
always call ttm_bo_wait_free_node() and also skip the add_fence? Or
maybe this case should rather be moved into the driver, and handled
with something along the lines of ttm_bo_move_null()? Any thoughts
here?

Re: ttm_bo_move_sync_cleanup() issue

[Christian König]

Am 08.04.22 um 18:01 schrieb Matthew Auld:
> Hi Christian,
>
> We seem to be hitting a new issue in ttm_bo_move_sync_cleanup(), due
> to passing a NULL fence, and I guess with some recent changes this is
> now blowing up in at least dma_resv_add_fence(). Question is how
> should we handle this? Should we add a special case in
> ttm_bo_move_accel_cleanup() in case of NULL fence, and then maybe just
> always call ttm_bo_wait_free_node() and also skip the add_fence? Or
> maybe this case should rather be moved into the driver, and handled
> with something along the lines of ttm_bo_move_null()? Any thoughts
> here?

Ah, crap I though I've catched all cases where somebody wants to insert 
a NULL fence into the dma_resv object.

For the short term we should probably do as you suggested, e.g. always 
use ttm_bo_wait_free_node().

In the long term we should just completely nuke ttm_bo_wait_free_node() 
and directly cleanup properly here.

Regards,
Christian.