From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>,
iommu@lists.linux-foundation.org,
Douglas Anderson <dianders@chromium.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/arm-smmu: Demote error messages to debug in shutdown callback
Date: Sat, 28 Mar 2020 13:05:17 +0530 [thread overview]
Message-ID: <d60196b548e1241b8334fadd0e8c2fb5@codeaurora.org> (raw)
In-Reply-To: <5858bdac-b7f9-ac26-0c0d-c9653cef841d@arm.com>
Hi Robin,
On 2020-03-28 00:32, Robin Murphy wrote:
> On 2020-03-27 3:09 pm, Sai Prakash Ranjan wrote:
>
> Imagine your network driver doesn't implement a .shutdown method (so
> the hardware is still active regardless of device links), happens to
> have an Rx buffer or descriptor ring DMA-mapped at an IOVA that looks
> like the physical address of the memory containing some part of the
> kernel text lower down that call stack, and the MAC receives a
> broadcast IP packet at about the point arm_smmu_device_shutdown() is
> returning. Enjoy debugging that ;)
>
> And if coincidental memory corruption seems too far-fetched for your
> liking, other fun alternatives might include "display tries to scan
> out from powered-off device, deadlocks interconnect and prevents
> anything else making progress", or "access to TZC-protected physical
> address triggers interrupt and over-eager Secure firmware resets
> system before orderly poweroff has a chance to finish".
>
> Of course the fact that in practice we'll *always* see the warning
> because there's no way to tear down the default DMA domains, and even
> if all devices *have* been nicely quiesced there's no way to tell, is
> certainly less than ideal. Like I say, it's not entirely clear-cut
> either way...
>
Thanks for these examples, good to know these scenarios in case we come
across these.
However, if we see these error/warning messages appear everytime then
what will be
the credibility of these messages? We will just ignore these messages
when
these issues you mention actually appears because we see them everytime
on
reboot or shutdown. So doesn't it make sense to enable these only when
we are debugging? We could argue that how will we know the issue could
be related
to SMMU, but that's the case even now.
The reason why this came up was that, we had a NOC(interconnect) error
which does
have a logging atleast in QCOM platforms from the secure side(it prints
these on the console)
after the SMMU err messages and there was a confusion if it was related
to these messages.
However, NOC error messages did identify the issue with the USB and it
was solved later.
So these SMMU err/warning messages could be misleading like the above
case almost everytime.
The probability of the issues you mentioned occuring is very less than
the actual reboot,
shutdown scenarios, for ex: we run reboot stress test for thousands of
times and these messages
don't add anything special in those cases when any issue occurs because
they are seen
everytime.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2020-03-28 7:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 13:28 [PATCH] iommu/arm-smmu: Demote error messages to debug in shutdown callback Sai Prakash Ranjan
2020-03-27 14:12 ` Robin Murphy
2020-03-27 15:09 ` Sai Prakash Ranjan
2020-03-27 16:17 ` Rob Clark
2020-03-27 18:18 ` Sai Prakash Ranjan
2020-03-27 19:02 ` Robin Murphy
2020-03-28 7:35 ` Sai Prakash Ranjan [this message]
2020-03-30 18:24 ` Doug Anderson
2020-03-31 7:36 ` Sai Prakash Ranjan
2020-03-31 7:44 ` Will Deacon
2020-03-31 7:53 ` Sai Prakash Ranjan
2020-04-22 19:49 ` Doug Anderson
2020-04-23 8:17 ` Sai Prakash Ranjan
2020-04-23 9:28 ` Robin Murphy
2020-04-23 9:41 ` Sai Prakash Ranjan
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=d60196b548e1241b8334fadd0e8c2fb5@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=dianders@chromium.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@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).