public inbox for linux-kernel@vger.kernel.org
 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: Wed, 7 Sep 2022 09:46:28 +0100	[thread overview]
Message-ID: <ef7622de-c1f3-c6cd-a50e-bbcbf8288b64@huawei.com> (raw)
In-Reply-To: <ad67a859-dc57-e30f-e422-3f9a0cb5239b@arm.com>

On 06/09/2022 19:25, Robin Murphy wrote:
>>
>> 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.
> 
> Yeah, there's a lot not to like about iommu_dma_init_domain() - I've 
> been banking on it all getting cleaned up when I get to refactoring that 
> area of probing (remember the issue you reported years ago with PCI 
> groups being built in the wrong order? All related...), but in fact 
> since the cookie management got pulled into core code, we can probably 
> tie the IOVA domain setup to that right now without much other 
> involvement. That could be a cheap win, so I'll give it a go soon.

ok, great.

On a related topic, another thing to consider is that errors in IOVA 
domain init are not handled gracefully in terms of how we deal with the 
device probe and setting dma mapping ops, ref iommu_setup_dma_ops(). I 
assume you know all this.

> 
>> - 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.
> 
> Sure, like I say I'm happy to be consistent either way. If I do end up 
> reinstating such a check I think I'd prefer to have it explicit in 
> {alloc,free}_iova_fast() anyway, rather than buried in internal 
> implementation details.

I'm not sure what you would like to see now, if anything.

I could just remove the iovad->rcache check in iova_rcache_get().  It's 
pretty useless (on its own) since we don't have the same check on the 
"insert" path.

Or also add this:

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 0d6d8edf782d..e8f0b8f47f45 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -578,6 +578,12 @@ static int iommu_dma_init_domain(struct 
iommu_domain *domain, dma_addr_t base,
  			goto done_unlock;
  		}

+		if (!iovad->rcaches) {
+			pr_warn("IOVA domain rcache not properly initialised\n");
+			ret = -EFAULT;
+			goto done_unlock;
+		}
+
  		ret = 0;
  		goto done_unlock;


But I figure that you don't want more crud there now, considering the 
work you mention above.

Thanks,
John




  reply	other threads:[~2022-09-07  8:46 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
2022-09-06 18:25           ` Robin Murphy
2022-09-07  8:46             ` John Garry [this message]
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=ef7622de-c1f3-c6cd-a50e-bbcbf8288b64@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