HailoRT 4.24 PCIe driver: VMA lifetime after mmap_read_unlock() in hailo_vdma_buffer_map()

General Discussion
, ,
1

Hi,

I’m preparing to upgrade a Raspberry Pi 5 with a Hailo-8 from HailoRT/PCIe driver 4.23.0 to the official HailoRT 4.24.0 ARM64 packages from the Hailo Developer Zone.

System details:

  • Raspberry Pi 5, ARM64

  • Raspberry Pi OS / Debian 13 (Trixie)

  • Kernel: 6.18.50+rpt-rpi-2712

  • Accelerator: Hailo-8

  • Current HailoRT/PCIe driver/firmware: 4.23.0

  • Proposed upgrade: HailoRT/PCIe driver/firmware 4.24.0

With 4.23.0, hardware inference works, but it produces kernel WARN traces involving find_vma() from hailo_vdma_buffer_map(). I understand this is a known issue in 4.23 related to calling find_vma() without the appropriate mmap_read_lock().

Before installing 4.24 on this system, I inspected the 4.24 PCIe driver source. I can see that 4.24 adds mmap_read_lock() / mmap_read_unlock() around the find_vma() lookup, which appears to address the original warning.

However, I have a question about the lifetime of the returned VMA after the lock is released.

In the 4.24 linux/vdma/memory.c code path, mmap_read_lock() protects find_vma(), but the lock appears to be released before subsequent use/dereferencing of the returned VMA, including accesses associated with is_dmabuf_vma(), create_fd_from_vma(), and the MMIO path.

What mechanism guarantees that the VMA and associated vm_file remain valid after mmap_read_unlock()?

Is this intentional and safe on current Linux kernels, or is additional VMA lifetime protection required/planned?

I have not yet installed or tested 4.24 on this host because I wanted to clarify this before loading the driver on a production system. I’m happy to provide the relevant source excerpts, 4.23 kernel WARN traces, or additional system information if useful.

Thanks!