All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2 10/11] iommu/vt-d: Use xarray for global device_domain_info
Date: Mon, 14 Feb 2022 10:00:38 -0400	[thread overview]
Message-ID: <20220214140038.GB4160@nvidia.com> (raw)
In-Reply-To: <20220214025704.3184654-11-baolu.lu@linux.intel.com>

On Mon, Feb 14, 2022 at 10:57:03AM +0800, Lu Baolu wrote:
> Replace the existing global device_domain_list with an array so that it
> could be rapidly searched. The index of the array is composed by the PCI
> segment, bus and devfn. Use RCU for lock protection.
> 
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>  include/linux/intel-iommu.h |  1 -
>  drivers/iommu/intel/iommu.c | 72 ++++++++++++++++++-------------------
>  2 files changed, 34 insertions(+), 39 deletions(-)
> 
> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index 03f1134fc2fe..aca1c1cc04a8 100644
> +++ b/include/linux/intel-iommu.h
> @@ -610,7 +610,6 @@ struct intel_iommu {
>  /* PCI domain-device relationship */
>  struct device_domain_info {
>  	struct list_head link;	/* link to domain siblings */
> -	struct list_head global; /* link to global list */
>  	struct list_head table;	/* link to pasid table */
>  	u32 segment;		/* PCI segment number */
>  	u8 bus;			/* PCI bus number */
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index fb17ed8c08f3..ecec923ce191 100644
> +++ b/drivers/iommu/intel/iommu.c
> @@ -131,8 +131,6 @@ static struct intel_iommu **g_iommus;
>  
>  static void __init check_tylersburg_isoch(void);
>  static int rwbf_quirk;
> -static inline struct device_domain_info *
> -dmar_search_domain_by_dev_info(int segment, int bus, int devfn);
>  
>  /*
>   * set to 1 to panic kernel if can't successfully enable VT-d
> @@ -318,30 +316,34 @@ int intel_iommu_gfx_mapped;
>  EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
>  
>  DEFINE_SPINLOCK(device_domain_lock);
> -static LIST_HEAD(device_domain_list);
> +static DEFINE_XARRAY_ALLOC(device_domain_array);

The 'device_domain_lock' should be replaced by the internal xarray
spinlock, no reason to have two locks.

> +
> +/* Convert device source ID into the index of device_domain_array. */
> +static inline unsigned long devi_idx(unsigned long seg, u8 bus, u8 devfn)
> +{
> +	return (seg << 16) | PCI_DEVID(bus, devfn);
> +}
>  
>  /*
> - * Iterate over elements in device_domain_list and call the specified
> + * Iterate over elements in device_domain_array and call the specified
>   * callback @fn against each element.
>   */
>  int for_each_device_domain(int (*fn)(struct device_domain_info *info,
>  				     void *data), void *data)
>  {
> -	int ret = 0;
> -	unsigned long flags;
>  	struct device_domain_info *info;
> +	unsigned long index;
> +	int ret = 0;
>  
> -	spin_lock_irqsave(&device_domain_lock, flags);
> -	list_for_each_entry(info, &device_domain_list, global) {
> +	rcu_read_lock();
> +	xa_for_each(&device_domain_array, index, info) {
>  		ret = fn(info, data);
> -		if (ret) {
> -			spin_unlock_irqrestore(&device_domain_lock, flags);
> -			return ret;
> -		}
> +		if (ret)
> +			break;

And you probably shouldn't try to use RCU. It is really unclear how
this function can be useful while racing against
intel_iommu_release_device(), eg today the only user of this function
does:

static int search_pasid_table(struct device_domain_info *info, void *opaque)
{
	struct pasid_table_opaque *data = opaque;

	if (info->iommu->segment == data->segment &&
	    info->bus == data->bus &&
	    info->devfn == data->devfn &&

And even if you kfree_rcu(info) then 'info->iommu->' is still racy
unlocked.

RCU is complicated to use, it is not just a drop in replacement for a
spinlock.

Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>, Kevin Tian <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>, Liu Yi L <yi.l.liu@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 10/11] iommu/vt-d: Use xarray for global device_domain_info
Date: Mon, 14 Feb 2022 10:00:38 -0400	[thread overview]
Message-ID: <20220214140038.GB4160@nvidia.com> (raw)
In-Reply-To: <20220214025704.3184654-11-baolu.lu@linux.intel.com>

On Mon, Feb 14, 2022 at 10:57:03AM +0800, Lu Baolu wrote:
> Replace the existing global device_domain_list with an array so that it
> could be rapidly searched. The index of the array is composed by the PCI
> segment, bus and devfn. Use RCU for lock protection.
> 
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>  include/linux/intel-iommu.h |  1 -
>  drivers/iommu/intel/iommu.c | 72 ++++++++++++++++++-------------------
>  2 files changed, 34 insertions(+), 39 deletions(-)
> 
> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index 03f1134fc2fe..aca1c1cc04a8 100644
> +++ b/include/linux/intel-iommu.h
> @@ -610,7 +610,6 @@ struct intel_iommu {
>  /* PCI domain-device relationship */
>  struct device_domain_info {
>  	struct list_head link;	/* link to domain siblings */
> -	struct list_head global; /* link to global list */
>  	struct list_head table;	/* link to pasid table */
>  	u32 segment;		/* PCI segment number */
>  	u8 bus;			/* PCI bus number */
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index fb17ed8c08f3..ecec923ce191 100644
> +++ b/drivers/iommu/intel/iommu.c
> @@ -131,8 +131,6 @@ static struct intel_iommu **g_iommus;
>  
>  static void __init check_tylersburg_isoch(void);
>  static int rwbf_quirk;
> -static inline struct device_domain_info *
> -dmar_search_domain_by_dev_info(int segment, int bus, int devfn);
>  
>  /*
>   * set to 1 to panic kernel if can't successfully enable VT-d
> @@ -318,30 +316,34 @@ int intel_iommu_gfx_mapped;
>  EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
>  
>  DEFINE_SPINLOCK(device_domain_lock);
> -static LIST_HEAD(device_domain_list);
> +static DEFINE_XARRAY_ALLOC(device_domain_array);

The 'device_domain_lock' should be replaced by the internal xarray
spinlock, no reason to have two locks.

> +
> +/* Convert device source ID into the index of device_domain_array. */
> +static inline unsigned long devi_idx(unsigned long seg, u8 bus, u8 devfn)
> +{
> +	return (seg << 16) | PCI_DEVID(bus, devfn);
> +}
>  
>  /*
> - * Iterate over elements in device_domain_list and call the specified
> + * Iterate over elements in device_domain_array and call the specified
>   * callback @fn against each element.
>   */
>  int for_each_device_domain(int (*fn)(struct device_domain_info *info,
>  				     void *data), void *data)
>  {
> -	int ret = 0;
> -	unsigned long flags;
>  	struct device_domain_info *info;
> +	unsigned long index;
> +	int ret = 0;
>  
> -	spin_lock_irqsave(&device_domain_lock, flags);
> -	list_for_each_entry(info, &device_domain_list, global) {
> +	rcu_read_lock();
> +	xa_for_each(&device_domain_array, index, info) {
>  		ret = fn(info, data);
> -		if (ret) {
> -			spin_unlock_irqrestore(&device_domain_lock, flags);
> -			return ret;
> -		}
> +		if (ret)
> +			break;

And you probably shouldn't try to use RCU. It is really unclear how
this function can be useful while racing against
intel_iommu_release_device(), eg today the only user of this function
does:

static int search_pasid_table(struct device_domain_info *info, void *opaque)
{
	struct pasid_table_opaque *data = opaque;

	if (info->iommu->segment == data->segment &&
	    info->bus == data->bus &&
	    info->devfn == data->devfn &&

And even if you kfree_rcu(info) then 'info->iommu->' is still racy
unlocked.

RCU is complicated to use, it is not just a drop in replacement for a
spinlock.

Jason

  parent reply	other threads:[~2022-02-14 14:00 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-14  2:56 [PATCH v2 00/11] iommu/vt-d: Some Intel IOMMU cleanups Lu Baolu
2022-02-14  2:56 ` Lu Baolu
2022-02-14  2:56 ` [PATCH v2 01/11] iommu/vt-d: Remove intel_iommu::domains Lu Baolu
2022-02-14  2:56   ` Lu Baolu
2022-02-24 12:58   ` Jason Gunthorpe via iommu
2022-02-24 12:58     ` Jason Gunthorpe
2022-02-14  2:56 ` [PATCH v2 02/11] iommu/vt-d: Remove finding domain in dmar_insert_one_dev_info() Lu Baolu
2022-02-14  2:56   ` Lu Baolu
2022-02-24 12:59   ` Jason Gunthorpe via iommu
2022-02-24 12:59     ` Jason Gunthorpe
2022-02-14  2:56 ` [PATCH v2 03/11] iommu/vt-d: Remove iova_cache_get/put() Lu Baolu
2022-02-14  2:56   ` Lu Baolu
2022-02-24 13:00   ` Jason Gunthorpe via iommu
2022-02-24 13:00     ` Jason Gunthorpe
2022-02-14  2:56 ` [PATCH v2 04/11] iommu/vt-d: Remove domain and devinfo mempool Lu Baolu
2022-02-14  2:56   ` Lu Baolu
2022-02-24 13:01   ` Jason Gunthorpe via iommu
2022-02-24 13:01     ` Jason Gunthorpe
2022-02-14  2:56 ` [PATCH v2 05/11] iommu/vt-d: Remove DEFER_DEVICE_DOMAIN_INFO Lu Baolu
2022-02-14  2:56   ` Lu Baolu
2022-02-14  7:31   ` Christoph Hellwig
2022-02-14  7:31     ` Christoph Hellwig
2022-02-24 13:04   ` Jason Gunthorpe via iommu
2022-02-24 13:04     ` Jason Gunthorpe
2022-02-25  1:55     ` Lu Baolu
2022-02-25  1:55       ` Lu Baolu
2022-02-14  2:56 ` [PATCH v2 06/11] iommu/vt-d: Remove unnecessary includes Lu Baolu
2022-02-14  2:56   ` Lu Baolu
2022-02-14  7:32   ` Christoph Hellwig
2022-02-14  7:32     ` Christoph Hellwig
2022-02-24 13:05   ` Jason Gunthorpe via iommu
2022-02-24 13:05     ` Jason Gunthorpe
2022-02-25  1:56     ` Lu Baolu
2022-02-25  1:56       ` Lu Baolu
2022-02-14  2:57 ` [PATCH v2 07/11] iommu/vt-d: Remove unnecessary prototypes Lu Baolu
2022-02-14  2:57   ` Lu Baolu
2022-02-14  7:32   ` Christoph Hellwig
2022-02-14  7:32     ` Christoph Hellwig
2022-02-24 13:05   ` Jason Gunthorpe via iommu
2022-02-24 13:05     ` Jason Gunthorpe
2022-02-14  2:57 ` [PATCH v2 08/11] iommu/vt-d: Fix indentation of goto labels Lu Baolu
2022-02-14  2:57   ` Lu Baolu
2022-02-14  7:33   ` Christoph Hellwig
2022-02-14  7:33     ` Christoph Hellwig
2022-02-24 13:08   ` Jason Gunthorpe via iommu
2022-02-24 13:08     ` Jason Gunthorpe
2022-02-25  1:57     ` Lu Baolu
2022-02-25  1:57       ` Lu Baolu
2022-02-14  2:57 ` [PATCH v2 09/11] iommu/vt-d: Remove commented code Lu Baolu
2022-02-14  2:57   ` Lu Baolu
2022-02-14  7:34   ` Christoph Hellwig
2022-02-14  7:34     ` Christoph Hellwig
2022-02-16  3:45     ` Tian, Kevin
2022-02-16  3:45       ` Tian, Kevin
2022-02-16  7:11       ` Lu Baolu
2022-02-16  7:11         ` Lu Baolu
2022-02-24 13:09   ` Jason Gunthorpe via iommu
2022-02-24 13:09     ` Jason Gunthorpe
2022-02-25  1:53     ` Lu Baolu
2022-02-25  1:53       ` Lu Baolu
2022-02-14  2:57 ` [PATCH v2 10/11] iommu/vt-d: Use xarray for global device_domain_info Lu Baolu
2022-02-14  2:57   ` Lu Baolu
2022-02-14  7:38   ` Christoph Hellwig
2022-02-14  7:38     ` Christoph Hellwig
2022-02-15  5:54     ` Lu Baolu
2022-02-15  5:54       ` Lu Baolu
2022-02-14 14:00   ` Jason Gunthorpe via iommu [this message]
2022-02-14 14:00     ` Jason Gunthorpe
2022-02-15  5:46     ` Lu Baolu
2022-02-15  5:46       ` Lu Baolu
2022-02-14  2:57 ` [PATCH v2 11/11] iommu/vt-d: Use rculist for per-domain device list Lu Baolu
2022-02-14  2:57   ` Lu Baolu

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=20220214140038.GB4160@nvidia.com \
    --to=iommu@lists.linux-foundation.org \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=hch@lst.de \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    /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.