Balancing ttm_mem_io_reserve() and ttm_mem_io_free()

[Christian König]

Hi Thomas,

IIRC we intentionally dropped that approach of balancing 
ttm_mem_io_reserve()/ttm_mem_io_free().

Instead the results from ttm_mem_io_reserve() are cached and that cached 
information is freed by ttm_mem_io_free(). In other words every time we 
need to make sure we have the cache filled we call ttm_mem_io_reserve() 
and everytime we are about to free the resource or don't need the 
mapping any more we call ttm_mem_io_free().

The callbacks to io_mem_reserve() and io_mem_free() are then balanced.

Fixing missing _free() calls in the error path is probably a good idea, 
but I wouldn't go beyond that.

Why should any of that be racy? You need to hold the reservation lock to 
call any of those functions.

Regards,
Christian.

Am 19.08.22 um 10:13 schrieb Thomas Hellström:
> Hi Christian,
>
> I'm looking for a way to take some sort of reference across possible 
> VRAM accesses  over the PCI bar, be it for runtime PM, workarounds or 
> whatever.
>
> The ttm_mem_io_reserve/free seems like a good candidate, but is 
> completely unbalanced and looks racy. In particular error paths forget 
> to call ttm_mem_io_free().
>
> Would you have any objections if I took a look at attempting to 
> balance calls to those functions, or do you have any other suggestions 
> for a better method?
>
> Thanks,
>
> Thomas
>
>
>