All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roedel, Joerg" <Joerg.Roedel@amd.com>
To: Chris Wright <chrisw@sous-sol.org>
Cc: "iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/9] x86/amd-iommu: Introduce global dev_data_list
Date: Sat, 11 Jun 2011 12:27:54 +0200	[thread overview]
Message-ID: <20110611102754.GB29908@amd.com> (raw)
In-Reply-To: <20110610173604.GM23047@sequoia.sous-sol.org>

On Fri, Jun 10, 2011 at 01:36:04PM -0400, Chris Wright wrote:
> * Joerg Roedel (joerg.roedel@amd.com) wrote:
> > +static struct iommu_dev_data *alloc_dev_data(void)
> > +{
> > +	struct iommu_dev_data *dev_data;
> > +	unsigned long flags;
> > +
> > +	dev_data = kzalloc(sizeof(*dev_data), GFP_KERNEL);
> > +	if (!dev_data)
> > +		return NULL;
> > +
> > +	atomic_set(&dev_data->bind, 0);
> > +
> > +	spin_lock_irqsave(&dev_data_list_lock, flags);
> > +	list_add_tail(&dev_data->dev_data_list, &dev_data_list);
> > +	spin_unlock_irqrestore(&dev_data_list_lock, flags);
> 
> Globally visible but only paritially initiailized.  I didn't see any, but
> would this ever cause an issue?

I don't think so. Everything allocated here goes into iommu_init_device
where the alias-part of the struct is initialized. As long as this is
the only place that calls find_dev_data everything is fine.

> > +static void free_dev_data(struct iommu_dev_data *dev_data)
> > +{
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&dev_data_list_lock, flags);
> > +	list_del(&dev_data->dev_data_list);
> > +	spin_unlock_irqrestore(&dev_data_list_lock, flags);
> > +
> > +	kfree(dev_data);
> <snip>
> > +	/* Free all of our dev_data structures */
> > +	list_for_each_entry_safe(dev_data, n, &dev_data_list, dev_data_list)
> > +		free_dev_data(dev_data);
> 
> Given that it's not actually contended in early init, should be fine...but
> typically full list traversal would be protected by lock rather than
> repeatedly acquiring and releasing the lock.

Well, the lock shouldn't be necessary here at all. This function is
called in the error-path to clean up. Otherwise the dev_data structures
are never freed, so the lock can probably be removed from free_dev_data.

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632


  reply	other threads:[~2011-06-11 10:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-10 12:08 [PATCH 0/9] AMD IOMMU: Reduce dependency to struct device Joerg Roedel
2011-06-10 12:08 ` [PATCH 1/9] x86/amd-iommu: Remove redundant device_flush_dte() calls Joerg Roedel
2011-06-10 12:08 ` [PATCH 2/9] x86/amd-iommu: Introduce global dev_data_list Joerg Roedel
2011-06-10 17:36   ` Chris Wright
2011-06-11 10:27     ` Roedel, Joerg [this message]
2011-06-10 12:08 ` [PATCH 3/9] x86/amd-iommu: Store devid in dev_data Joerg Roedel
2011-06-10 12:08 ` [PATCH 4/9] x86/amd-iommu: Store ATS state " Joerg Roedel
2011-06-10 12:08 ` [PATCH 5/9] x86/amd-iommu: Use only dev_data for dte and iotlb flushing routines Joerg Roedel
2011-06-10 12:08 ` [PATCH 6/9] x86/amd-iommu: Use only dev_data in low-level domain attach/detach functions Joerg Roedel
2011-06-10 12:08 ` [PATCH 7/9] x86/amd-iommu: Allow dev_data->alias to be NULL Joerg Roedel
2011-06-10 12:08 ` [PATCH 8/9] x86/amd-iommu: Search for existind dev_data before allocting a new one Joerg Roedel
2011-06-10 20:52   ` Chris Wright
2011-06-11 10:29     ` Roedel, Joerg
2011-06-10 12:08 ` [PATCH 9/9] x86/amd-iommu: Store device alias as dev_data pointer Joerg Roedel

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=20110611102754.GB29908@amd.com \
    --to=joerg.roedel@amd.com \
    --cc=chrisw@sous-sol.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.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.