On 19/05/2023 14:32, Jason Gunthorpe wrote: > On Thu, May 18, 2023 at 09:46:27PM +0100, Joao Martins wrote: >> From: Lu Baolu <baolu.lu@xxxxxxxxxxxxxxx> >> >> The IOMMU page tables are updated using iommu_map/unmap() interfaces. >> Currently, there is no mandatory requirement for drivers to use locks >> to ensure concurrent updates to page tables, because it's assumed that >> overlapping IOVA ranges do not have concurrent updates. Therefore the >> IOMMU drivers only need to take care of concurrent updates to level >> page table entries. >> >> But enabling new features challenges this assumption. For example, the >> hardware assisted dirty page tracking feature requires scanning page >> tables in interfaces other than mapping and unmapping. This might result >> in a use-after-free scenario in which a level page table has been freed >> by the unmap() interface, while another thread is scanning the next level >> page table. > > I'm not convinced.. The basic model we have is that the caller has to > bring the range locking and the caller has to promise it doesn't do > overlapping things to ranges. > > iommufd implements this with area based IOVA range locking. > Right > So, I don't really see an obvious reason why we can't also require > that the dirty reporting hold the area lock and domain locks while it > is calling the iommu driver? > > Then we don't have a locking or RCU problem here. > I would rather keep base on area range locking -- I think I got confused from this other thread discussion on having RCU for the iopte walks. I'll remove it from the series for now, and if later deemed needed it should come as a separate thing.
