linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
	linux-arm-kernel@lists.infradead.org,
	Will Deacon <will@kernel.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Heiko Stuebner <heiko@sntech.de>, Joerg Roedel <jroedel@suse.de>,
	Jerry Snitselaar <jsnitsel@redhat.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Steven Price <steven.price@arm.com>
Subject: Re: [PATCH 4/7] iommu/arm-smmu: Pass arm_smmu_domain to arm_smmu_init_domain_context()
Date: Fri, 6 Oct 2023 10:53:47 -0300	[thread overview]
Message-ID: <20231006135347.GR682044@nvidia.com> (raw)
In-Reply-To: <db259336-1203-4d12-ac80-3108aaf5ec82@arm.com>

On Fri, Oct 06, 2023 at 02:43:51PM +0100, Robin Murphy wrote:
> On 2023-10-05 19:28, Jason Gunthorpe wrote:
> > Instead of putting container_of() casts in the internals, use the proper
> > type in this call chain. This makes it easier to check that the two global
> > static domains are not leaking into call chains they should not.
>
> Is there something inherently difficult about to_smmu_domain()? It's hard to
> tell how the aforementioned checks might expect to work since they don't
> appear to be added anywhere :/

?? There are not added checks, this is talking about static checks and
code auditing.

Let's try the commit paragraph again:

Now that we have IDENTITY and BLOCKED domains that do not use the
struct arm_smmu_domain it is important that to_smmu_domain() is only
called on iommu_domain structs passed to the paging domain ops (aka
default_domain_ops). Use the more specific type in several call
chains and remove the few to_smmu_domain() calls that are not
obviously in an op call chain.

This makes it easier to audit the code that the two IDENTITY and
BLOCKED domains are not leaking someplace they should not.

> > @@ -616,7 +616,6 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
> >   	struct io_pgtable_ops *pgtbl_ops;
> >   	struct io_pgtable_cfg pgtbl_cfg;
> >   	enum io_pgtable_fmt fmt;
> > -	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> 
> If at all, I think I'd rather just flip this to a local "struct iommu_domain
> *domain = &smmu_domain->domain;" and avoid the hunk of churn below.

Sure

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-10-06 13:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05 18:28 [PATCH 0/7] Convert SMMU to domain_alloc_paging() Jason Gunthorpe
2023-10-05 18:28 ` [PATCH 1/7] iommu/arm-smmu: Reorganize arm_smmu_domain_add_master() Jason Gunthorpe
2023-10-06 12:05   ` Robin Murphy
2023-10-06 12:30     ` Jason Gunthorpe
2023-10-06 13:45       ` Robin Murphy
2023-10-05 18:28 ` [PATCH 2/7] iommu/arm-smmu: Convert to a global static identity domain Jason Gunthorpe
2023-10-05 18:28 ` [PATCH 3/7] iommu/arm-smmu: Implement IOMMU_DOMAIN_BLOCKED Jason Gunthorpe
2023-10-05 18:28 ` [PATCH 4/7] iommu/arm-smmu: Pass arm_smmu_domain to arm_smmu_init_domain_context() Jason Gunthorpe
2023-10-06 13:43   ` Robin Murphy
2023-10-06 13:53     ` Jason Gunthorpe [this message]
2023-10-06 14:56       ` Robin Murphy
2023-10-06 15:03         ` Jason Gunthorpe
2023-10-06 15:11   ` Steven Price
2023-10-06 16:23     ` Jason Gunthorpe
2023-10-05 18:28 ` [PATCH 5/7] iommu/arm-smmu: Convert to domain_alloc_paging() Jason Gunthorpe
2023-10-05 18:28 ` [PATCH 6/7] iommu: Compute dev_iommu->require_direct sooner Jason Gunthorpe
2023-10-05 18:28 ` [PATCH 7/7] iommu: Restore SMMU "disable_bypass" Jason Gunthorpe
2023-10-06 12:06   ` Robin Murphy
2023-10-06 12:41     ` Jason Gunthorpe
2023-11-30  0:49 ` [PATCH 0/7] Convert SMMU to domain_alloc_paging() Jason Gunthorpe
2023-12-11 14:14   ` Joerg Roedel
2023-12-11 14:22     ` Jason Gunthorpe
2023-12-11 15:40     ` Will Deacon

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=20231006135347.GR682044@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=heiko@sntech.de \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=jroedel@suse.de \
    --cc=jsnitsel@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=m.szyprowski@samsung.com \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=steven.price@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).