Re: Balancing ttm_mem_io_reserve() and ttm_mem_io_free()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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







[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux