All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: David Woodhouse <dwmw2@infradead.org>,
	Chris Wright <chrisw@sous-sol.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>
Cc: Mike Habeck <habeck@sgi.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	stable@kernel.org, iommu@lists.linux-foundation.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 3/7] Intel pci: Dont cache iova above 32bit
Date: Thu, 26 May 2011 20:32:24 -0500	[thread overview]
Message-ID: <20110527013221.693830597@gulag1.americas.sgi.com> (raw)
In-Reply-To: 20110527013221.231071058@gulag1.americas.sgi.com

[-- Attachment #1: dont-cache-iova-above-32bit.patch --]
[-- Type: text/plain, Size: 2193 bytes --]

Mike Travis and Mike Habeck reported an issue where iova allocation
would return a range that was larger than a device's dma mask.

https://lkml.org/lkml/2011/3/29/423

The dmar initialization code will reserve all PCI MMIO regions and copy
those reservations into a domain specific iova tree.  It is possible for
one of those regions to be above the dma mask of a device.  It is typical
to allocate iovas with a 32bit mask (despite device's dma mask possibly
being larger) and cache the result until it exhausts the lower 32bit
address space.  Freeing the iova range that is >= the last iova in the
lower 32bit range when there is still an iova above the 32bit range will
corrupt the cached iova by pointing it to a region that is above 32bit.
If that region is also larger than the device's dma mask, a subsequent
allocation will return an unusable iova and cause dma failure.

Simply don't cache an iova that is above the 32bit caching boundary.

From: Chris Wright <chrisw@sous-sol.org>
Reported-by: Mike Travis <travis@sgi.com>
Reported-by: Mike Habeck <habeck@sgi.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: stable@kernel.org
Acked-by: Mike Travis <travis@sgi.com>
Tested-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

v3: rb_next() can return NULL, found when testing on my hw

David, Mike Travis will collect and resumbit full series when he's back.

 drivers/pci/iova.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- linux.orig/drivers/pci/iova.c
+++ linux/drivers/pci/iova.c
@@ -63,8 +63,16 @@ __cached_rbnode_delete_update(struct iov
 	curr = iovad->cached32_node;
 	cached_iova = container_of(curr, struct iova, node);
 
-	if (free->pfn_lo >= cached_iova->pfn_lo)
-		iovad->cached32_node = rb_next(&free->node);
+	if (free->pfn_lo >= cached_iova->pfn_lo) {
+		struct rb_node *node = rb_next(&free->node);
+		struct iova *iova = container_of(node, struct iova, node);
+
+		/* only cache if it's below 32bit pfn */
+		if (node && iova->pfn_lo < iovad->dma_32bit_pfn)
+			iovad->cached32_node = node;
+		else
+			iovad->cached32_node = NULL;
+	}
 }
 
 /* Computes the padding size required, to make the

-- 

  parent reply	other threads:[~2011-05-27  1:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-27  1:32 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
2011-05-27  1:32 ` [PATCH 1/7] Intel pci: Check for identity mapping candidate using system dma mask Mike Travis
2011-05-27  7:18   ` [stable] " Greg KH
2011-05-27  9:30     ` Ingo Molnar
2011-05-27  9:42       ` Joerg Roedel
2011-05-27  9:59         ` Greg KH
2011-05-27  1:32 ` [PATCH 2/7] Intel pci: Speed up processing of the identity_mapping function Mike Travis
2011-05-27  1:32 ` Mike Travis [this message]
2011-05-27  1:32 ` [PATCH 4/7] Intel pci: Use coherent DMA mask when requested Mike Travis
2011-05-27  1:32 ` [PATCH 5/7] Intel pci: Remove Host Bridge devices from identity mapping Mike Travis
2011-05-27  1:32 ` [PATCH 6/7] Intel pci: Add domain check in domain_remove_one_dev_info Mike Travis
2011-05-27  1:32 ` [PATCH 7/7] Intel pci: Indicate 64-bit IOMMU passthrough available Mike Travis
2011-05-27 15:01   ` David Woodhouse
2011-05-28 18:15 [PATCH 0/7] Intel pci: Fix various problems with Intel IOMMU code Mike Travis
2011-05-28 18:15 ` [PATCH 3/7] Intel pci: Dont cache iova above 32bit Mike Travis

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=20110527013221.693830597@gulag1.americas.sgi.com \
    --to=travis@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=chrisw@sous-sol.org \
    --cc=dwmw2@infradead.org \
    --cc=habeck@sgi.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stable@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.