From: Naresh Kamboju <naresh.kamboju@linaro.org>
To: Rob Clark <robdclark@gmail.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
Arnd Bergmann <arnd@arndb.de>, Sean Paul <sean@poorly.run>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Joerg Roedel <jroedel@suse.de>,
Vinod Koul <vinod.koul@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
freedreno <freedreno@lists.freedesktop.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Andy Gross <agross@kernel.org>,
lkft-triage@lists.linaro.org,
open list <linux-kernel@vger.kernel.org>,
Eric Anholt <eric@anholt.net>,
"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Thierry Reding <thierry.reding@gmail.com>,
John Stultz <john.stultz@linaro.org>,
"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
"moderated list:ARM/Mediatek SoC..."
<linux-mediatek@lists.infradead.org>,
Will Deacon <will@kernel.org>
Subject: Re: [Freedreno] arm64: Internal error: Oops: qcom_iommu_tlb_inv_context free_io_pgtable_ops on db410c
Date: Tue, 21 Jul 2020 00:49:23 +0530 [thread overview]
Message-ID: <CA+G9fYv9K3FqR6D9=2jvQ3s_eSTL=K-x4QW4-P7=AgfjjHCBwA@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGsBRxFC918nNzJZnxMpFnNC6qcNGvMjjM8U3AAn6CusNA@mail.gmail.com>
On Mon, 20 Jul 2020 at 21:27, Rob Clark <robdclark@gmail.com> wrote:
>
> On Mon, Jul 20, 2020 at 4:28 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > On 2020-07-20 08:17, Arnd Bergmann wrote:
> > > On Mon, Jul 20, 2020 at 8:36 AM Naresh Kamboju
> > > <naresh.kamboju@linaro.org> wrote:
<>
> > >> [ 5.444121] Unable to handle kernel NULL pointer dereference at
> > >> virtual address 0000000000000018
> > >> [ 5.456615] ESR = 0x96000004
> > >> [ 5.464471] SET = 0, FnV = 0
> > >> [ 5.464487] EA = 0, S1PTW = 0
> > >> [ 5.466521] Data abort info:
> > >> [ 5.469971] ISV = 0, ISS = 0x00000004
> > >> [ 5.472768] CM = 0, WnR = 0
> > >> [ 5.476172] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000bacba000
> > >> [ 5.479349] [0000000000000018] pgd=0000000000000000, p4d=0000000000000000
> > >> [ 5.485820] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > >> [ 5.492448] Modules linked in: crct10dif_ce adv7511(+)
> > >> qcom_spmi_temp_alarm cec msm(+) mdt_loader qcom_camss videobuf2_dma_sg
> > >> drm_kms_helper v4l2_fwnode videobuf2_memops videobuf2_v4l2 qcom_rng
> > >> videobuf2_common i2c_qcom_cci display_connector socinfo drm qrtr ns
> > >> rmtfs_mem fuse
> > >> [ 5.500256] CPU: 0 PID: 286 Comm: systemd-udevd Not tainted 5.8.0-rc5 #1
> > >> [ 5.522484] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> > >> [ 5.529170] pstate: 20000005 (nzCv daif -PAN -UAO BTYPE=--)
> > >> [ 5.535856] pc : qcom_iommu_tlb_inv_context+0x18/0xa8
> > >> [ 5.541148] lr : free_io_pgtable_ops+0x28/0x58
<>
> > >> [ 5.628297] Call trace:
> > >> [ 5.633592] qcom_iommu_tlb_inv_context+0x18/0xa8
> > >
> > > This means that dev_iommu_fwspec_get() has returned NULL
> > > in qcom_iommu_tlb_inv_context(), either because dev->iommu
> > > is NULL, or because dev->iommu->fwspec is NULL.
> > >
> > > qcom_iommu_tlb_inv_context() does not check for a NULL
> > > pointer before using the returned object.
> > >
> > > The bug is either in the lack of error handling, or the fact
> > > that it's possible to get into this function for a device
> > > that has not been fully set up.
> >
> > Not quite - the device *was* properly set up, but has already been
> > properly torn down again in the removal path by iommu_release_device().
> > The problem is that qcom-iommu kept the device pointer as its TLB cookie
> > for the domain, but the domain has a longer lifespan than the validity
> > of that device - that's a fundamental design flaw in the driver.
>
> fwiw, I just sent "iommu/qcom: Use domain rather than dev as tlb
> cookie".. untested but looks like a straightforward enough change to
> switch over to using the domain rather than dev as cookie
The proposed patch tested and confirmed the reported problem fixed.
ref:
https://lore.kernel.org/linux-iommu/CA+G9fYtj1RBYcPhXZRm-qm5ygtdLj1jD8vFZSqQvwi_DNJLBwQ@mail.gmail.com/T/#m36a1fca18098f6c34275d928f9ba9c40c6d7fd63
https://lkft.validation.linaro.org/scheduler/job/1593950#L3392
>
> BR,
> -R
- Naresh
WARNING: multiple messages have this Message-ID (diff)
From: Naresh Kamboju <naresh.kamboju@linaro.org>
To: Rob Clark <robdclark@gmail.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
"moderated list:ARM/Mediatek SoC..."
<linux-mediatek@lists.infradead.org>,
Joerg Roedel <jroedel@suse.de>,
Vinod Koul <vinod.koul@linaro.org>, Arnd Bergmann <arnd@arndb.de>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
"Guohanjun \(Hanjun Guo\)" <guohanjun@huawei.com>,
open list <linux-kernel@vger.kernel.org>,
lkft-triage@lists.linaro.org, Eric Anholt <eric@anholt.net>,
"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Andy Gross <agross@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
John Stultz <john.stultz@linaro.org>,
freedreno <freedreno@lists.freedesktop.org>,
Sean Paul <sean@poorly.run>
Subject: Re: [Freedreno] arm64: Internal error: Oops: qcom_iommu_tlb_inv_context free_io_pgtable_ops on db410c
Date: Tue, 21 Jul 2020 00:49:23 +0530 [thread overview]
Message-ID: <CA+G9fYv9K3FqR6D9=2jvQ3s_eSTL=K-x4QW4-P7=AgfjjHCBwA@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGsBRxFC918nNzJZnxMpFnNC6qcNGvMjjM8U3AAn6CusNA@mail.gmail.com>
On Mon, 20 Jul 2020 at 21:27, Rob Clark <robdclark@gmail.com> wrote:
>
> On Mon, Jul 20, 2020 at 4:28 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > On 2020-07-20 08:17, Arnd Bergmann wrote:
> > > On Mon, Jul 20, 2020 at 8:36 AM Naresh Kamboju
> > > <naresh.kamboju@linaro.org> wrote:
<>
> > >> [ 5.444121] Unable to handle kernel NULL pointer dereference at
> > >> virtual address 0000000000000018
> > >> [ 5.456615] ESR = 0x96000004
> > >> [ 5.464471] SET = 0, FnV = 0
> > >> [ 5.464487] EA = 0, S1PTW = 0
> > >> [ 5.466521] Data abort info:
> > >> [ 5.469971] ISV = 0, ISS = 0x00000004
> > >> [ 5.472768] CM = 0, WnR = 0
> > >> [ 5.476172] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000bacba000
> > >> [ 5.479349] [0000000000000018] pgd=0000000000000000, p4d=0000000000000000
> > >> [ 5.485820] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > >> [ 5.492448] Modules linked in: crct10dif_ce adv7511(+)
> > >> qcom_spmi_temp_alarm cec msm(+) mdt_loader qcom_camss videobuf2_dma_sg
> > >> drm_kms_helper v4l2_fwnode videobuf2_memops videobuf2_v4l2 qcom_rng
> > >> videobuf2_common i2c_qcom_cci display_connector socinfo drm qrtr ns
> > >> rmtfs_mem fuse
> > >> [ 5.500256] CPU: 0 PID: 286 Comm: systemd-udevd Not tainted 5.8.0-rc5 #1
> > >> [ 5.522484] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> > >> [ 5.529170] pstate: 20000005 (nzCv daif -PAN -UAO BTYPE=--)
> > >> [ 5.535856] pc : qcom_iommu_tlb_inv_context+0x18/0xa8
> > >> [ 5.541148] lr : free_io_pgtable_ops+0x28/0x58
<>
> > >> [ 5.628297] Call trace:
> > >> [ 5.633592] qcom_iommu_tlb_inv_context+0x18/0xa8
> > >
> > > This means that dev_iommu_fwspec_get() has returned NULL
> > > in qcom_iommu_tlb_inv_context(), either because dev->iommu
> > > is NULL, or because dev->iommu->fwspec is NULL.
> > >
> > > qcom_iommu_tlb_inv_context() does not check for a NULL
> > > pointer before using the returned object.
> > >
> > > The bug is either in the lack of error handling, or the fact
> > > that it's possible to get into this function for a device
> > > that has not been fully set up.
> >
> > Not quite - the device *was* properly set up, but has already been
> > properly torn down again in the removal path by iommu_release_device().
> > The problem is that qcom-iommu kept the device pointer as its TLB cookie
> > for the domain, but the domain has a longer lifespan than the validity
> > of that device - that's a fundamental design flaw in the driver.
>
> fwiw, I just sent "iommu/qcom: Use domain rather than dev as tlb
> cookie".. untested but looks like a straightforward enough change to
> switch over to using the domain rather than dev as cookie
The proposed patch tested and confirmed the reported problem fixed.
ref:
https://lore.kernel.org/linux-iommu/CA+G9fYtj1RBYcPhXZRm-qm5ygtdLj1jD8vFZSqQvwi_DNJLBwQ@mail.gmail.com/T/#m36a1fca18098f6c34275d928f9ba9c40c6d7fd63
https://lkft.validation.linaro.org/scheduler/job/1593950#L3392
>
> BR,
> -R
- Naresh
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Naresh Kamboju <naresh.kamboju@linaro.org>
To: Rob Clark <robdclark@gmail.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
"moderated list:ARM/Mediatek SoC..."
<linux-mediatek@lists.infradead.org>,
Joerg Roedel <jroedel@suse.de>,
Vinod Koul <vinod.koul@linaro.org>, Arnd Bergmann <arnd@arndb.de>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
"Guohanjun \(Hanjun Guo\)" <guohanjun@huawei.com>,
open list <linux-kernel@vger.kernel.org>,
lkft-triage@lists.linaro.org, Eric Anholt <eric@anholt.net>,
"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Andy Gross <agross@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
John Stultz <john.stultz@linaro.org>,
freedreno <freedreno@lists.freedesktop.org>,
Sean Paul <sean@poorly.run>
Subject: Re: [Freedreno] arm64: Internal error: Oops: qcom_iommu_tlb_inv_context free_io_pgtable_ops on db410c
Date: Tue, 21 Jul 2020 00:49:23 +0530 [thread overview]
Message-ID: <CA+G9fYv9K3FqR6D9=2jvQ3s_eSTL=K-x4QW4-P7=AgfjjHCBwA@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGsBRxFC918nNzJZnxMpFnNC6qcNGvMjjM8U3AAn6CusNA@mail.gmail.com>
On Mon, 20 Jul 2020 at 21:27, Rob Clark <robdclark@gmail.com> wrote:
>
> On Mon, Jul 20, 2020 at 4:28 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > On 2020-07-20 08:17, Arnd Bergmann wrote:
> > > On Mon, Jul 20, 2020 at 8:36 AM Naresh Kamboju
> > > <naresh.kamboju@linaro.org> wrote:
<>
> > >> [ 5.444121] Unable to handle kernel NULL pointer dereference at
> > >> virtual address 0000000000000018
> > >> [ 5.456615] ESR = 0x96000004
> > >> [ 5.464471] SET = 0, FnV = 0
> > >> [ 5.464487] EA = 0, S1PTW = 0
> > >> [ 5.466521] Data abort info:
> > >> [ 5.469971] ISV = 0, ISS = 0x00000004
> > >> [ 5.472768] CM = 0, WnR = 0
> > >> [ 5.476172] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000bacba000
> > >> [ 5.479349] [0000000000000018] pgd=0000000000000000, p4d=0000000000000000
> > >> [ 5.485820] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > >> [ 5.492448] Modules linked in: crct10dif_ce adv7511(+)
> > >> qcom_spmi_temp_alarm cec msm(+) mdt_loader qcom_camss videobuf2_dma_sg
> > >> drm_kms_helper v4l2_fwnode videobuf2_memops videobuf2_v4l2 qcom_rng
> > >> videobuf2_common i2c_qcom_cci display_connector socinfo drm qrtr ns
> > >> rmtfs_mem fuse
> > >> [ 5.500256] CPU: 0 PID: 286 Comm: systemd-udevd Not tainted 5.8.0-rc5 #1
> > >> [ 5.522484] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> > >> [ 5.529170] pstate: 20000005 (nzCv daif -PAN -UAO BTYPE=--)
> > >> [ 5.535856] pc : qcom_iommu_tlb_inv_context+0x18/0xa8
> > >> [ 5.541148] lr : free_io_pgtable_ops+0x28/0x58
<>
> > >> [ 5.628297] Call trace:
> > >> [ 5.633592] qcom_iommu_tlb_inv_context+0x18/0xa8
> > >
> > > This means that dev_iommu_fwspec_get() has returned NULL
> > > in qcom_iommu_tlb_inv_context(), either because dev->iommu
> > > is NULL, or because dev->iommu->fwspec is NULL.
> > >
> > > qcom_iommu_tlb_inv_context() does not check for a NULL
> > > pointer before using the returned object.
> > >
> > > The bug is either in the lack of error handling, or the fact
> > > that it's possible to get into this function for a device
> > > that has not been fully set up.
> >
> > Not quite - the device *was* properly set up, but has already been
> > properly torn down again in the removal path by iommu_release_device().
> > The problem is that qcom-iommu kept the device pointer as its TLB cookie
> > for the domain, but the domain has a longer lifespan than the validity
> > of that device - that's a fundamental design flaw in the driver.
>
> fwiw, I just sent "iommu/qcom: Use domain rather than dev as tlb
> cookie".. untested but looks like a straightforward enough change to
> switch over to using the domain rather than dev as cookie
The proposed patch tested and confirmed the reported problem fixed.
ref:
https://lore.kernel.org/linux-iommu/CA+G9fYtj1RBYcPhXZRm-qm5ygtdLj1jD8vFZSqQvwi_DNJLBwQ@mail.gmail.com/T/#m36a1fca18098f6c34275d928f9ba9c40c6d7fd63
https://lkft.validation.linaro.org/scheduler/job/1593950#L3392
>
> BR,
> -R
- Naresh
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
next prev parent reply other threads:[~2020-07-20 19:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-20 6:35 arm64: Internal error: Oops: qcom_iommu_tlb_inv_context free_io_pgtable_ops on db410c Naresh Kamboju
2020-07-20 6:35 ` Naresh Kamboju
2020-07-20 6:35 ` Naresh Kamboju
2020-07-20 7:17 ` Arnd Bergmann
2020-07-20 7:17 ` Arnd Bergmann
2020-07-20 7:17 ` Arnd Bergmann
2020-07-20 11:28 ` Robin Murphy
2020-07-20 11:28 ` Robin Murphy
2020-07-20 11:28 ` Robin Murphy
2020-07-20 15:58 ` [Freedreno] " Rob Clark
2020-07-20 15:58 ` Rob Clark
2020-07-20 15:58 ` Rob Clark
2020-07-20 19:19 ` Naresh Kamboju [this message]
2020-07-20 19:19 ` Naresh Kamboju
2020-07-20 19:19 ` Naresh Kamboju
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='CA+G9fYv9K3FqR6D9=2jvQ3s_eSTL=K-x4QW4-P7=AgfjjHCBwA@mail.gmail.com' \
--to=naresh.kamboju@linaro.org \
--cc=agross@kernel.org \
--cc=arnd@arndb.de \
--cc=eric@anholt.net \
--cc=freedreno@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=john.stultz@linaro.org \
--cc=jroedel@suse.de \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=lkft-triage@lists.linaro.org \
--cc=matthias.bgg@gmail.com \
--cc=robdclark@gmail.com \
--cc=robin.murphy@arm.com \
--cc=sean@poorly.run \
--cc=sudeep.holla@arm.com \
--cc=thierry.reding@gmail.com \
--cc=vinod.koul@linaro.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.