Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Christian Schrefl <chrisi.schrefl@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>, Jason Gunthorpe <jgg@ziepe.ca>
Cc: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	Rob Clark <robin.clark@oss.qualcomm.com>,
	Matti Vaittinen <mazziesaccount@gmail.com>,
	iommu@lists.linux.dev, linux-arm-msm@vger.kernel.org,
	Rudraksha Gupta <guptarud@gmail.com>
Subject: Re: [REGRESSION] qcom: iommu: nullpointer dereference on boot on apq8064
Date: Fri, 23 Jan 2026 19:10:58 +0100	[thread overview]
Message-ID: <ab9103dd-c1c6-473b-9dd7-87a3d5e203c9@gmail.com> (raw)
In-Reply-To: <da3fcb7f-4ac4-41c0-b3ad-055c6766fd5c@arm.com>

Hi Robin

On 1/23/26 7:02 PM, Robin Murphy wrote:
> On 2026-01-15 7:02 pm, Christian Schrefl wrote:
>> Hi Robin,
>>
>> Sorry for taking so long until I got to trying it out.
>> The patch fixes the crash!
> 
> Bah, in the process of writing this up properly I've realised that although it fixes the crash, I think it breaks the multi-IOMMU functionality, as .add_device will only be called for the first IOMMU instance, whereas the current code is cheekily abusing .of_xlate to link the device to both instances. And in fact that implies the existing code is yet more buggy, as it seems it will leak and reallocate dev_iommu_priv the first time it looks up the second instance (whose ctx_list will be empty), thus it's only working at all because in all cases the DT happens to list all the IDs for one instance before all for the other, and both use an identical set of ID values. Oh dear...

Thanks for looking into this! I'm not familiar with the IOMMU subsystem so it would probably take me a long
time to figure out anything useful about this.

> Are you using the GPU and/or display device(s) enough to be able to tell whether their IOMMUs are working as expected?
No I currently only have a serial console, though at least the display used to work on earlier versions,
but maybe that's just a configuration issue. Its on my list to investigate when I've got the time for it.

Cheers,
Christian


      reply	other threads:[~2026-01-23 18:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-29 22:26 [REGRESSION] qcom: iommu: nullpointer dereference on boot on apq8064 Christian Schrefl
2026-01-05 18:02 ` Jason Gunthorpe
2026-01-06 18:50   ` Robin Murphy
2026-01-15 19:02     ` Christian Schrefl
2026-01-23 18:02       ` Robin Murphy
2026-01-23 18:10         ` Christian Schrefl [this message]

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=ab9103dd-c1c6-473b-9dd7-87a3d5e203c9@gmail.com \
    --to=chrisi.schrefl@gmail.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=guptarud@gmail.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=mazziesaccount@gmail.com \
    --cc=robin.clark@oss.qualcomm.com \
    --cc=robin.murphy@arm.com \
    /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