linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Robin Murphy <robin.murphy@arm.com>,
	Ethan Zhao <haifeng.zhao@linux.intel.com>, <joro@8bytes.org>,
	<will@kernel.org>
Cc: <iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
	<linuxarm@huawei.com>
Subject: Re: [PATCH v2 1/2] iova: Remove some magazine pointer NULL checks
Date: Tue, 6 Sep 2022 18:36:58 +0100	[thread overview]
Message-ID: <cc950d77-2a97-ac75-4a1d-19aaf864a3be@huawei.com> (raw)
In-Reply-To: <555fa5aa-a575-d783-dc97-79f63dcf2f57@arm.com>

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

  reply	other threads:[~2022-09-06 17:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05  9:11 [PATCH v2 0/2] iova: Some misc changes John Garry
2022-09-05  9:11 ` [PATCH v2 1/2] iova: Remove some magazine pointer NULL checks John Garry
2022-09-05 15:06   ` Jerry Snitselaar
2022-09-06  9:28   ` Ethan Zhao
2022-09-06 10:50     ` John Garry
2022-09-06 13:37       ` Robin Murphy
2022-09-06 17:36         ` John Garry [this message]
2022-09-06 18:25           ` Robin Murphy
2022-09-07  8:46             ` John Garry
2022-09-07  9:05               ` Robin Murphy
2022-09-07  9:58               ` Ethan Zhao
2022-09-07 10:10                 ` John Garry
2022-09-07  9:33       ` Ethan Zhao
2022-09-07  9:53         ` John Garry
2022-09-05  9:11 ` [PATCH v2 2/2] iova: Remove magazine BUG_ON() checks John Garry
2022-09-05 15:06   ` Jerry Snitselaar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cc950d77-2a97-ac75-4a1d-19aaf864a3be@huawei.com \
    --to=john.garry@huawei.com \
    --cc=haifeng.zhao@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).