DMA Safety in Buffers for Linux Kernel Device Drivers
summary
Work on I2C finds that externally supplied message buffers are often not DMA-safe, so an opt-in DMA_SAFE flag and a small helper API now exist that either validates the buffer or provides a bounce buffer and cleanup helper; this fixes real crashes in controllers that assume DMA access. Kernel development tooling helps — enable CONFIG_DMA_API_DEBUG during testing — but wider auditing is needed because issues range from vmalloc vs kmalloc placement to device-specific address window limits.
AI-written summary · about
chapters (13)
- 0:00Intro
- 0:53Why use DMA
- 3:38Two potential code paths
- 9:20ISquareC client side
- 13:20Other subsystems
- 14:21SPI
- 17:00Unexpected Issues
- 20:20Conclusions
- 21:22Debugging
- 21:52DMA Buff
- 23:30Subsystem Maintainer
- 24:15Developers
- 25:06Linux Foundation
related talks
39mTaming DMA: Tales Wrestling Memory Corruption
20mProtected DMAbufs and its dynamic memory assignment woes- 39mTaming DMA: Tales Wrestling Memory Corruption
34mPreventing DMA Attacks from Thunderbolt Devices
37mPreventing DMA Attacks from Thunderbolt Devices
50mExporting Virtual Memory as dmabuf
47mLinux on POWER Driver Porting, Optimization, and Test
24mA Virtual IOMMU With Cooperative DMA Buffer Tracking