iommu_probe_device
ops->probe_finalize(dev);
intel_iommu_probe_finalize
iommu_setup_dma_ops
iommu_dma_init_domain(domain, dma_base, dma_limit, dev)
iova_domain_init_rcaches
{
...
cpu_rcache->loaded = iova_magazine_alloc(GFP_KERNEL);
cpu_rcache->prev = iova_magazine_alloc(GFP_KERNEL);
if (!cpu_rcache->loaded || !cpu_rcache->prev) {
ret = -ENOMEM;
goto out_err;
Do you mean iova_magazine_alloc() is impossible to fail ?
No, iova_magazine_alloc() may fail and return NULL. But if it does then we set iovad rcache pointer = NULL in the error path and don't use the rcache.
However we have a !iovad->rcache check on the "fast" alloc but not "insert". I need to check why that is again.
Right, if you find a good reason to respin the patch then perhaps also tweaking the commit message to clarify that it's impossible to have a NULL rcache *at any point where those checks are made* might avoid all possible doubt, however I'd hope that it's clear enough that the transient case while iova_domain_init_rcaches() is in the process of failing really doesn't need consideration in its own right.
I guess the check in iova_rcache_get() was maybe with the intent of allowing alloc_iova_fast() to seamlessly fall back to standard allocation, so an API user can treat iova_domain_init_rcaches() failure as non-fatal?
That makes a fair amount of sense, but does mean that we're missing the equivalent in iova_rcache_insert() for it to actually work. Or we just remove it and tighten up the documentation to say that's not valid
- I would like a way to make rcaches optional in iommu-dma for systems where they're a pointless waste of memory, but we can always revisit this when we get there.