On 2022/3/21 20:50, Jason Gunthorpe wrote:
On Sun, Mar 20, 2022 at 02:40:29PM +0800, Lu Baolu wrote:
+static enum iommu_page_response_code
+iommu_sva_handle_iopf(struct iommu_fault *fault, void *data)
+{
+ vm_fault_t ret;
+ struct mm_struct *mm;
+ struct vm_area_struct *vma;
+ unsigned int access_flags = 0;
+ struct iommu_domain *domain = data;
Why is the iommu_domain not passed in as a fully typed object? I would
think data should some opaque value used by non-sva cases.
The "data" is set together with the fault handler when the caller
installs a fault handler for an iommu domain. We will add a generic
interface to install fault handler for an iommu domain later when a real
non-sva case comes.
What is the lifetime model here anyhow?
I simply thought that the device driver should guarantee that there are
no pending faults after sva_unbind(). This is insufficient. I need to
rework this.
+ unsigned int fault_flags = FAULT_FLAG_REMOTE;
+ struct iommu_fault_page_request *prm = &fault->prm;
+ enum iommu_page_response_code status = IOMMU_PAGE_RESP_INVALID;
+
+ if (!(prm->flags & IOMMU_FAULT_PAGE_REQUEST_PASID_VALID))
+ return status;
+
+ mm = domain->sva_cookie;
+ if (IS_ERR_OR_NULL(mm))
Do not use this function
Do not store err pointers in structs.
Sure.
+out_put_mm:
+ mmap_read_unlock(mm);
+ mmput(mm);
mm structs are weird, they have two refcounts.
The 'sva_cookie' should hold a mmgrab/mmdrop() refcount to keep the
pointer alive but to touch the mmap lock you have to upgrade it to a
refcount that prevents destruction using mmget_not_zero() just for
this short period.
Yes. Will look into it.
Best regards,
baolu
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
