lkml.org 
[lkml]   [2022]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/2] iova: Remove some magazine pointer NULL checks
>>>
>>> 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.

Yeah, I would think so. But I still don't mind tweaking it to be extra
clear.

>
> 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?

The 2x users treat iova_domain_init_rcaches() as fatal:
- dma-iommu falls back to platform ops in iommu_setup_dma_ops()

Caveat: on the chance that the IOVA domain init fails due to the rcache
init failing, then, if there were another device in the group which
probes later, its probe would be ok as the start_pfn is set. Not Good.

- vdpa just fails to create the domain in vduse_domain_create()

> 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'd be more inclined to remove it. I would rather remove fathpath checks
as much as possible and have robust error handling in the domain init.

Afterall I do have the "remove check" craze going.

> - 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.
>

thanks,
John

\
 
 \ /
  Last update: 2022-09-06 19:40    [W:0.190 / U:1.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site