All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Nicolin Chen <nicolinc@nvidia.com>, jgg@nvidia.com, kevin.tian@intel.com
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	joro@8bytes.org, will@kernel.org, robin.murphy@arm.com
Subject: Re: [PATCH rc 2/2] iommufd/fault: Use a separate spinlock to protect fault->deliver list
Date: Wed, 15 Jan 2025 13:24:53 +0800	[thread overview]
Message-ID: <1cbee44f-4fce-4e9c-8b95-cd1fa25f5921@linux.intel.com> (raw)
In-Reply-To: <56c73c27b572e9c677182e99b5244184bdef7541.1736894696.git.nicolinc@nvidia.com>

On 1/15/25 07:28, Nicolin Chen wrote:
> The fault->mutex was to serialize the fault read()/write() fops and the
> iommufd_fault_auto_response_faults(). And it was also conveniently used
> to protect fault->deliver in poll() and iommufd_fault_iopf_handler().
> 
> However, copy_from/to_user() may sleep if pagefaults are enabled. Thus,
> they could take a long time to wait for user pages to swap in, blocking
> iommufd_fault_iopf_handler() and its caller that is typically a shared
> IRQ handler of an IOMMU driver, resulting in a potential global DOS.
> 
> Instead of resuing the mutex to protect the fault->deliver list, add a
> separate spinlock to do the job, so iommufd_fault_iopf_handler() would
> no longer be blocked by copy_from/to_user().
> 
> Provide two list manipulation helpers for fault->deliver:
>   - Extract the first iopf_group out of the fault->deliver list
>   - Restore an iopf_group back to the head of the fault->deliver list
> 
> Replace list_first_entry and list_for_each accordingly.
> 
> Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object")
> Cc:stable@vger.kernel.org
> Suggested-by: Jason Gunthorpe<jgg@nvidia.com>
> Signed-off-by: Nicolin Chen<nicolinc@nvidia.com>
> ---
>   drivers/iommu/iommufd/iommufd_private.h | 26 +++++++++++++++
>   drivers/iommu/iommufd/fault.c           | 43 ++++++++++++++-----------
>   2 files changed, 50 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/iommu/iommufd/iommufd_private.h b/drivers/iommu/iommufd/iommufd_private.h
> index b6d706cf2c66..d3097c857abf 100644
> --- a/drivers/iommu/iommufd/iommufd_private.h
> +++ b/drivers/iommu/iommufd/iommufd_private.h
> @@ -445,12 +445,38 @@ struct iommufd_fault {
>   
>   	/* The lists of outstanding faults protected by below mutex. */

It's better to update above comment as well.

>   	struct mutex mutex;
> +	spinlock_t lock; /* protects the deliver list */
>   	struct list_head deliver;
>   	struct xarray response;
>   
>   	struct wait_queue_head wait_queue;
>   };
>   
> +/* Extract the first node out of the fault->deliver list */
> +static inline struct iopf_group *
> +iommufd_fault_deliver_extract(struct iommufd_fault *fault)
> +{
> +	struct list_head *list = &fault->deliver;
> +	struct iopf_group *group = NULL;
> +
> +	spin_lock(&fault->lock);
> +	if (!list_empty(list)) {
> +		group = list_first_entry(list, struct iopf_group, node);
> +		list_del(&group->node);
> +	}
> +	spin_unlock(&fault->lock);
> +	return group;
> +}
> +
> +/* Restore a node back to the head in fault->deliver */
> +static inline void iommufd_fault_deliver_restore(struct iommufd_fault *fault,
> +						 struct iopf_group *group)
> +{
> +	spin_lock(&fault->lock);
> +	list_add(&fault->deliver, &group->node);

This is not right. It should be

	list_add(&group->node, &fault->deliver);

> +	spin_unlock(&fault->lock);
> +}

Others look good to me. With above addressed,

Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>


  parent reply	other threads:[~2025-01-15  5:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-14 23:28 [PATCH rc 0/2] iommufd/fault: Two bug fixes prior to vEVENTQ Nicolin Chen
2025-01-14 23:28 ` [PATCH rc 1/2] iommufd/fault: Destroy response and mutex in iommufd_fault_destroy() Nicolin Chen
2025-01-15  0:54   ` Jason Gunthorpe
2025-01-15  5:17   ` Tian, Kevin
2025-01-15  5:21   ` Baolu Lu
2025-01-14 23:28 ` [PATCH rc 2/2] iommufd/fault: Use a separate spinlock to protect fault->deliver list Nicolin Chen
2025-01-15  5:24   ` Tian, Kevin
2025-01-15  5:40     ` Nicolin Chen
2025-01-15  5:24   ` Baolu Lu [this message]
2025-01-15  5:45     ` Nicolin Chen

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=1cbee44f-4fce-4e9c-8b95-cd1fa25f5921@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --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 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.