All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: <will@kernel.org>, <robin.murphy@arm.com>, <kevin.tian@intel.com>,
	<joro@8bytes.org>, <praan@google.com>, <kees@kernel.org>,
	<baolu.lu@linux.intel.com>, <miko.lenczewski@arm.com>,
	<smostafa@google.com>, <linux-arm-kernel@lists.infradead.org>,
	<iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
	<stable@vger.kernel.org>, <jamien@nvidia.com>
Subject: Re: [PATCH v5 1/6] iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump
Date: Tue, 19 May 2026 11:11:09 -0700	[thread overview]
Message-ID: <agynvTrzP3FGtQEi@Asurada-Nvidia> (raw)
In-Reply-To: <20260519171003.GD3602937@nvidia.com>

On Tue, May 19, 2026 at 02:10:03PM -0300, Jason Gunthorpe wrote:
> On Sun, May 10, 2026 at 02:23:00PM -0700, Nicolin Chen wrote:
> 
> > +#include <linux/dma-direct.h>
> 
> Nope, never do this, it is an internal header.

Hmm, I have included it for a wrong reason, yet it does mention
"IOMMU drivers".

/*
 * Internals of the DMA direct mapping implementation.  Only for use by the
 * DMA mapping code and IOMMU drivers.
 */

> > +/*
> > + * Adopting the crashed kernel's stream table has risks: the physical addresses
> > + * read from ARM_SMMU_STRTAB_BASE / L1 descriptors may be corrupted. Reject any
> > + * range that overlaps the kdump kernel's critical regions.
> > + */
> > +static bool arm_smmu_kdump_phys_is_corrupted(phys_addr_t base, size_t size)
[..]
> Something like this should not be in the smmu driver, this is some
> core kdump code. I'd drop it, I don't see other drivers doing this?

OK.

> > +static int arm_smmu_kdump_adopt_l2_strtab(struct arm_smmu_device *smmu, u32 sid,
> > +					  u32 l1_idx, u64 l2_dma, u32 span,
> > +					  struct arm_smmu_strtab_l2 **l2table)
> > +{
> > +	phys_addr_t base = dma_to_phys(smmu->dev, l2_dma);
> 
> The thing stored in the L2PTR is a *phys*, the HW doesn't support any
> kind of translation. When using dma_alloc_coherent we never get a phys
> so it uses the dma_addr_t and assumes it is == phys.
> 
> But on this flow this is *phys* and should remain phys. Never touch
> dma_addr_t.

Fixing that and other places too.
 
> > +static void arm_smmu_kdump_adopt_cleanup(struct arm_smmu_device *smmu, u32 fmt)
> > +{
> > +	struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> > +
> > +	if (fmt == STRTAB_BASE_CFG_FMT_2LVL) {
> > +		if (cfg->l2.l2ptrs)
> > +			devm_kfree(smmu->dev, cfg->l2.l2ptrs);
> > +		if (!IS_ERR_OR_NULL(cfg->l2.l1tab))
> > +			devm_memunmap(smmu->dev, cfg->l2.l1tab);
> > +	} else if (fmt == STRTAB_BASE_CFG_FMT_LINEAR) {
> > +		if (!IS_ERR_OR_NULL(cfg->linear.table))
> > +			devm_memunmap(smmu->dev, cfg->linear.table);
> > +	}
> > +}
> 
> If we have a cleanup function why is it using devm? Call the cleanup
> function during remove too?

Dropping "devm_"s.

Thanks
Nicolin

  reply	other threads:[~2026-05-19 18:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-10 21:22 [PATCH v5 0/6] iommu/arm-smmu-v3: Fix device crash on kdump kernel Nicolin Chen
2026-05-10 21:23 ` [PATCH v5 1/6] iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump Nicolin Chen
2026-05-19 17:10   ` Jason Gunthorpe
2026-05-19 18:11     ` Nicolin Chen [this message]
2026-05-10 21:23 ` [PATCH v5 2/6] iommu/arm-smmu-v3: Implement is_attach_deferred() " Nicolin Chen
2026-05-19 17:43   ` Jason Gunthorpe
2026-05-10 21:23 ` [PATCH v5 3/6] iommu/arm-smmu-v3: Suppress EVTQ/PRIQ events in kdump kernel Nicolin Chen
2026-05-19 17:44   ` Jason Gunthorpe
2026-05-19 20:13     ` Nicolin Chen
2026-05-19 22:27       ` Jason Gunthorpe
2026-05-10 21:23 ` [PATCH v5 4/6] iommu/arm-smmu-v3: Skip EVTQ/PRIQ setup " Nicolin Chen
2026-05-19 17:45   ` Jason Gunthorpe
2026-05-10 21:23 ` [PATCH v5 5/6] iommu/arm-smmu-v3: Retain CR0_SMMUEN during kdump device reset Nicolin Chen
2026-05-10 21:23 ` [PATCH v5 6/6] iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP_ADOPT in probe() Nicolin Chen
2026-05-19 17:58   ` Jason Gunthorpe

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=agynvTrzP3FGtQEi@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jamien@nvidia.com \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kees@kernel.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miko.lenczewski@arm.com \
    --cc=praan@google.com \
    --cc=robin.murphy@arm.com \
    --cc=smostafa@google.com \
    --cc=stable@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.