On Thu, Aug 22, 2024 at 11:37:11AM -0700, mhkelley58@xxxxxxxxx wrote: > Because it's not possible to detect at runtime whether a DMA map call > is made in a context that can block, the calls in key device drivers > must be updated with a MAY_BLOCK attribute, if appropriate. When this > attribute is set and swiotlb memory usage is above a threshold, the > swiotlb allocation code can serialize swiotlb memory usage to help > ensure that it is not exhausted. One thing I've been doing for a while but haven't gotten to due to my lack of semantic patching skills is that we really want to split the few flags useful for dma_map* from DMA_ATTR_* which largely only applies to dma_alloc. Only DMA_ATTR_WEAK_ORDERING (if we can't just kill it entirely) and for now DMA_ATTR_NO_WARN is used for both. DMA_ATTR_SKIP_CPU_SYNC and your new SLEEP/BLOCK attribute is only useful for mapping, and the rest is for allocation only. So I'd love to move to a DMA_MAP_* namespace for the mapping flags before adding more on potentially widely used ones. With a little grace period we can then also phase out DMA_ATTR_NO_WARN for allocations, as the gfp_t can control that much better. > In general, storage device drivers can take advantage of the MAY_BLOCK > option, while network device drivers cannot. The Linux block layer > already allows storage requests to block when the BLK_MQ_F_BLOCKING > flag is present on the request queue. Note that this also in general involves changes to the block drivers to set that flag, which is a bit annoying, but I guess there is not easy way around it without paying the price for the BLK_MQ_F_BLOCKING overhead everywhere.
