On Thu, Jul 10, 2025, at 07:59, Nicolin Chen wrote:
EXPORT_SYMBOL_NS_GPL(_iommufd_object_undepend, "IOMMUFD");
+/*
- Allocate an @offset to return to user space to use for an mmap()
syscall
- Driver should use a per-structure helper in include/linux/iommufd.h
- */
+int _iommufd_alloc_mmap(struct iommufd_ctx *ictx, struct iommufd_object *owner,
phys_addr_t mmio_addr, size_t length,unsigned long *offset)+{
...
- /* Skip the first page to ease caller identifying the returned offset
*/
- rc = mtree_alloc_range(&ictx->mt_mmap, &startp, immap, immap->length,
PAGE_SIZE, PHYS_ADDR_MAX, GFP_KERNEL);
This produces a warning on 32-bit targets with a 64-bit phys_addr_t, in practice this would be ARM Cortex-A15 or -A17 systems:
In file included from include/linux/overflow.h:6, ... from drivers/iommu/iommufd/driver.c:4: drivers/iommu/iommufd/driver.c: In function '_iommufd_alloc_mmap': include/linux/limits.h:11:25: error: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '18446744073709551615' to '4294967295' [-Werror=overflow] 11 | #define PHYS_ADDR_MAX (~(phys_addr_t)0) | ^~~~~~~~~~~~~~~~~ drivers/iommu/iommufd/driver.c:61:43: note: in expansion of macro 'PHYS_ADDR_MAX' 61 | PAGE_SIZE, PHYS_ADDR_MAX, GFP_KERNEL); | ^~~~~~~~~~~~~
The mtree_alloc_range() interface explicitly operates on 'unsigned long' address values, so I don't see an immediate workaround for this that would make it work on these machines. On the other hand,
At the moment, the only drivers that select CONFIG_IOMMUFD_DRIVER on 32-bit Arm systems are CONFIG_PDS_VFIO_PCI and CONFIG_MLX5_VFIO_PCI. It's probably fine to make all three symbols "depends on 64BIT" for now, but I don't know if there may be more drivers like this in the future that actually could make sense on embedded systems.
Arnd