On Fri, 23 Aug 2024 02:20:41 +0000 Michael Kelley <mhklinux@xxxxxxxxxxx> wrote: > From: Bart Van Assche <bvanassche@xxxxxxx> Sent: Thursday, August 22, 2024 12:29 PM > > > > On 8/22/24 11:37 AM, mhkelley58@xxxxxxxxx wrote: > > > Linux device drivers may make DMA map/unmap calls in contexts that > > > cannot block, such as in an interrupt handler. > > > > Although I really appreciate your work, what alternatives have been > > considered? How many drivers perform DMA mapping from atomic context? > > Would it be feasible to modify these drivers such that DMA mapping > > always happens in a context in which sleeping is allowed? > > > > I had assumed that allowing DMA mapping from interrupt context is a > long-time fundamental requirement that can't be changed. It's been > allowed at least for the past 20 years, as Linus added this statement to > kernel documentation in 2005: > > The streaming DMA mapping routines can be called from interrupt context. > > But I don't have any idea how many drivers actually do that. There are > roughly 1700 call sites in kernel code/drivers that call one of the > dma_map_*() variants, so looking through them all doesn't seem > feasible. Besides, calls from interrupt context are not the only calls which are not allowed to schedule (e.g. lock nesting comes to mind). Even if we agreed to make DMA mapping routines blocking, I believe the easiest way would be to start adding DMA_ATTR_MAY_BLOCK until it would be used by all drivers. ;-) But most importantly, if streaming DMA could block, there would be no need for a SWIOTLB, because you could simply allocate a bounce buffer from the buddy allocator when it's needed. Petr T
