linux-kernel - Re: [Bisected] [commit 2ad56efa80dba89162106c06ebc00b611325e584] [linux-next] WARNING while booting to kernel 6.6.0-rc3-next-20230929

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231004113818.GD682044@nvidia.com>
Date:   Wed, 4 Oct 2023 08:38:18 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Tasmiya Nalatwad <tasmiya@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
        baolu.lu@...ux.intel.com, jsnitsel@...hat.com, jroedel@...e.de,
        mpe@...erman.id.au, npiggin@...il.com, christophe.leroy@...roup.eu,
        gregkh@...uxfoundation.org, gbatra@...ux.vnet.ibm.com,
        ruscur@...sell.cc, linuxppc-dev@...ts.ozlabs.org,
        abdhalee@...ux.vnet.ibm.com, mputtash@...ux.vnet.com,
        sachinp@...ux.vnet.com
Subject: Re: [Bisected] [commit 2ad56efa80dba89162106c06ebc00b611325e584]
 [linux-next] WARNING while booting to kernel 6.6.0-rc3-next-20230929

On Wed, Oct 04, 2023 at 04:37:10PM +0530, Tasmiya Nalatwad wrote:
>    Greetings,
> 
>    [linux-next] [6.6.0-rc3-next-20230929] [git bisect ->
>    2ad56efa80dba89162106c06ebc00b611325e584]WARNING: CPU: 0 PID: 8 at
>    arch/powerpc/kernel/[1]iommu.c:407 __iommu_free+0x1e4/0x1f0
 
>    gitbisect is pointing to the below commit
>    commit 2ad56efa80dba89162106c06ebc00b611325e584
>        powerpc/iommu: Setup a default domain and remove set_platform_dma_ops
 
I assume this means there are still sequencing problems with power at
boot time. eg we turned on the dma ops in the wrong order or something
like that

As far as I can see the only difference here is that we do the
operation to claim dma ops during the iommu drive probe. We can avoid that.

Does this work for you?

diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index d6ad3fde85a212..115b9031badac7 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1280,13 +1280,19 @@ struct iommu_table_group_ops spapr_tce_table_group_ops = {
 /*
  * A simple iommu_ops to allow less cruft in generic VFIO code.
  */
-static int spapr_tce_platform_iommu_attach_dev(struct iommu_domain *dom,
-					       struct device *dev)
+static int
+spapr_tce_platform_iommu_attach_dev(struct iommu_domain *platform_domain,
+				    struct device *dev)
 {
+	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
 	struct iommu_group *grp = iommu_group_get(dev);
 	struct iommu_table_group *table_group;
 	int ret = -EINVAL;
 
+	/* At first attach the ownership is already set */
+	if (!domain)
+		return 0;
+
 	if (!grp)
 		return -ENODEV;