On Fri, Feb 13, 2026, at 11:44, Sami Tolvanen wrote: > The patches look reasonable to me, but I do wonder if examining > imported namespaces is the best way to distinguish between module > variants. Is looking at /sys/module/*/taint not sufficient for your > use case?
You're right that the example in the commit message is bad; it's true that the taint bit is strictly mutually exclusive with dmabuf support, at least for the way that this evolved in the nvidia open module. This is a patch I had in the back of my head for a while, and the details had become murkier since. The actual problem I wanted to solve with this was not with dmabuf being conditionally available on the exporter side (where the taint bit, albeit imprecise, would have worked), but with determining whether the ioctl was present on the import side, which was only true from 5.12 onward for uverbs (commit bfe0cc6). So on eg: a system with untainted nvidia-open on 5.10, it was viable to export dmabufs from device memory, but ibv_reg_dmabuf_mr would fail at runtime because the ioctl didn't exist yet. The workaround for my specific piece of middleware was just to call uname and check for 5.12+ before advertising dmabuf support back to the caller, but this left me feeling gross. In reality, this patch doesn't solve that problem, because any system running a new enough kernel to have this patch will already have support on both import/export sides. But it's what made me wish this functionality existed. Why I still hope you'll take this patch: 1. cheaply exposing module namespace imports under sysfs can be useful beyond this specific situation. The kernel is already tracking this and validating it for other reasons, so it's easy to also just expose it. 2. taint may not always be mutually exclusive with a module namespace import, eg: in the case of uverbs above. 3. currently, the only way to determine whether a module speaks dmabuf at runtime is to hardcode module-specific priors around the kernel version and/or the taint bit, or to link proprietary vendor libraries and check for things like CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED. Exposing this under sysfs provides a cheaper way for networking middleware (that doesn't usually allocate device memory itself and largely wishes to just blindly plumb dmabufs fds from callers into some importer in a vendor agnostic way) to determine what modules are in-play during initialization: > user@host$ grep DMA_BUF /sys/module/*/import_ns > /sys/module/amdgpu/import_ns:DMA_BUF > /sys/module/ib_uverbs/import_ns:DMA_BUF Critically, it can do this check without needing to link any vendor libraries. As an example, libfabric currently contains an enum for heterogeneous memory types, spanning ZE/ROCM/CUDA/SYNAPSEAI/NEURON... but libfabric doesn't need to allocate device memory itself (it is provided by the caller, hopefully as a dmabuf), and regardless of what module exported it, all roads will eventually lead back to a generic dmabuf fd import ioctl for the NIC. Despite that, to prevent memory registration errors at runtime before they happen, it needs to probe support for these memory types at initialization time. Today, that essentially means needing to link a new proprietary vendor library to query dmabuf export support using a vendor-specific API. But without any existing mechanism in the kernel to query known dmabuf importers or exporters, even a suboptimal one, this is what is done in practice. Best, Nicholas
