Linux中断处理程序如何访问物理地址？ioremap有哪些使用限制？

中断上下文属于原子上下文，执行过程中不允许发生任何调度、睡眠行为，而普通ioremap()的实现路径中存在大量可能触发睡眠的逻辑：包括使用GFP_KERNEL标识分配页表（允许内存回收、进程调度）、获取睡眠锁、操作vmalloc区域时可能触发VM相关调度，你遇到的KDB异常本质是内核检测到原子上下文调用睡眠函数触发的BUG，并非地址映射本身的访问错误。

你担心提前映射大量未使用内存造成资源浪费的顾虑可以通过以下方案规避，不需要映射全量地址空间：

• 使用原子版映射接口：调用ioremap_atomic()完成原子上下文下的临时地址映射，该接口专门为中断、持自旋锁临界区等原子场景设计，不会触发睡眠或调度，映射完成后即可直接访问物理地址，访问结束后立刻调用iounmap_atomic()释放映射即可。该接口不需要提前做全局映射，随用随映射，用完即释放，仅适合小范围地址的临时访问（受限于内核预留的固定映射槽位，不要映射超过几个页的范围）。
• 按需提前小范围映射：如果中断中访问的物理地址范围是固定的（比如外设的特定寄存器段、固定的数据缓冲区），完全不需要映射整个大物理地址空间，只需要在驱动初始化阶段，把中断里实际会访问到的几段小地址范围单独ioremap即可，映射后的虚拟地址存在驱动私有结构体中，中断里直接调用。这里需要澄清：ioremap建立的是内核虚拟地址到物理地址的页表映射，映射MMIO外设区域默认使用无缓存（UC）属性，不会占用CPU缓存，也不会分配实际物理内存页，仅占用极少量内核页表项内存（每映射4K地址仅占8字节左右的页表内存），即使映射几百K的地址范围，资源开销也可以忽略，不存在严重的资源浪费问题。
• 区分物理地址类型选择对应接口：如果你要访问的物理地址属于普通系统RAM（不是外设MMIO区域），不要用ioremap，直接使用kmap_atomic()映射对应的物理页，该接口同样是原子上下文安全的，访问完调用kunmap_atomic()释放即可。

• 上下文限制：普通版ioremap()/iounmap()严禁在原子上下文（硬中断、软中断、持自旋锁的临界区、RCU读侧临界区）调用，否则会直接触发内核BUG。
• 地址范围限制：严禁使用ioremap映射已经被内核线性映射的普通系统RAM物理地址，这类地址直接通过phys_to_virt()即可获取对应的内核虚拟地址，乱用ioremap映射RAM会造成地址别名、缓存一致性问题，引发内存损坏。
• 属性匹配限制：映射不同类型的物理地址必须选择匹配的缓存属性：外设控制寄存器必须使用无缓存属性的映射接口（ioremap_uc()/ioremap_nocache()），禁止使用带缓存的映射，否则会出现读写乱序、硬件状态不一致的问题；支持写合并的显存、帧缓冲类区域可以使用ioremap_wc()提升访问性能。
• 生命周期限制：ioremap返回的虚拟地址属于内核vmalloc地址区间，使用完成必须调用对应版本的iounmap释放，否则会造成vmalloc地址空间泄漏、页表项泄漏，长期运行会耗尽内核虚拟地址空间。
• 大小限制：原子版本的ioremap_atomic()受限于内核预留的固定映射槽位，不能映射过大的连续物理区域，仅适合临时小范围映射使用。

如果你在中断里访问的物理地址是不固定的、临时需要访问的小范围地址，优先用ioremap_atomic()/iounmap_atomic()在中断内随用随映射释放，完全不需要提前做映射，也不会触发异常。
如果中断里访问的是固定的外设寄存器或固定缓冲区，直接在驱动初始化阶段按需映射实际用到的地址段即可，资源开销极低，不存在浪费问题，性能也比临时映射更好。

内容的提问来源于stack exchange，提问作者Yonatan Amir