From: Pranjal Shrivastava <praan@google.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Will Deacon <will@kernel.org>,
Mostafa Saleh <smostafa@google.com>,
iommu@lists.linux.dev, Kunkun Jiang <jiangkunkun@huawei.com>,
Jason Gunthorpe <jgg@nvidia.com>
Subject: Re: [PATCH v2] iommu: Handle iommu faults for a bad iopf setup
Date: Thu, 15 Aug 2024 18:14:26 +0000 [thread overview]
Message-ID: <Zr5Fgl3v_sp8Ei0g@google.com> (raw)
In-Reply-To: <13778702-717d-4b7e-8ead-3ba86bfe55bd@arm.com>
On Thu, Aug 15, 2024 at 03:03:07PM +0100, Robin Murphy wrote:
> On 15/08/2024 1:46 pm, Pranjal Shrivastava wrote:
> [...]> @@ -155,22 +208,37 @@ static struct iopf_group
> *iopf_group_alloc(struct iommu_fault_param *iopf_param,
> > * hardware has been set to block the page faults) and the pending page faults
> > * have been flushed.
> > */
> > -void iommu_report_device_fault(struct device *dev, struct iopf_fault *evt)
> > +int iommu_report_device_fault(struct device *dev, struct iopf_fault *evt)
> > {
> > + struct iommu_attach_handle *attach_handle;
> > struct iommu_fault *fault = &evt->fault;
> > struct iommu_fault_param *iopf_param;
> > struct iopf_group abort_group = {};
> > struct iopf_group *group;
> > + int ret = 0;
> > + attach_handle = find_fault_handler(dev, evt);
> > + if (!attach_handle) {
> > + ret = -EINVAL;
> > + goto err_bad_iopf;
> > + }
> > +
> > + /*
> > + * Something has gone wrong if a fault capable domain is attached but no
> > + * iopf_param is setup
> > + */
> > iopf_param = iopf_get_dev_fault_param(dev);
> > - if (WARN_ON(!iopf_param))
> > - return;
> > + if (WARN_ON(!iopf_param)) {
> > + ret = -EINVAL;
> > + goto err_bad_iopf;
>
> Nit: the err_bad_iopf path is only ever returning -EINVAL, so you could
> simply hard-code that there...
>
> > + }
> > if (!(fault->prm.flags & IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE)) {
> > - report_partial_fault(iopf_param, fault);
> > + ret = report_partial_fault(iopf_param, fault);
>
> ...and declare "ret" here in the one scope it's actually needed.
Sure, will refactor this in the next version. Let me also swap the
signed-off-bys and prefix with rc as suggested by Jason in v3.
>
> Thanks,
> Robin.
>
> > iopf_put_dev_fault_param(iopf_param);
> > /* A request that is not the last does not need to be ack'd */
> > - return;
> > +
> > + return ret;
> > }
> > /*
Thanks,
Pranjal
prev parent reply other threads:[~2024-08-15 18:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 12:46 [PATCH v2] iommu: Handle iommu faults for a bad iopf setup Pranjal Shrivastava
2024-08-15 13:03 ` Jason Gunthorpe
2024-08-15 14:03 ` Robin Murphy
2024-08-15 18:14 ` Pranjal Shrivastava [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=Zr5Fgl3v_sp8Ei0g@google.com \
--to=praan@google.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jiangkunkun@huawei.com \
--cc=joro@8bytes.org \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.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 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.