From: "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>
To: akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Cc: ak@suse.de, gregkh@suse.de, muli@il.ibm.com,
suresh.b.siddha@intel.com, arjan@linux.intel.com,
ashok.raj@intel.com, davem@davemloft.net, clameter@sgi.com,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Subject: [Intel IOMMU 06/10] Avoid memory allocation failures in dma map api calls
Date: Tue, 19 Jun 2007 14:37:07 -0700 [thread overview]
Message-ID: <20070619213808.798646000@askeshav-devel.jf.intel.com> (raw)
In-Reply-To: <20070619213701.219910000@askeshav-devel.jf.intel.com>
[-- Attachment #1: intel_iommu_pf_memalloc.patch --]
[-- Type: text/plain, Size: 3662 bytes --]
Intel IOMMU driver needs memory during DMA map calls to setup its internal
page tables and for other data structures. As we all know that these DMA
map calls are mostly called in the interrupt context or with the spinlock
held by the upper level drivers(network/storage drivers), so in order to
avoid any memory allocation failure due to low memory issues,
this patch makes memory allocation by temporarily setting PF_MEMALLOC
flags for the current task before making memory allocation calls.
We evaluated mempools as a backup when kmem_cache_alloc() fails
and found that mempools are really not useful here because
1) We don;t know for sure how much to reserve in advance
2) And mempools are not useful for GFP_ATOMIC case (as we call
memory alloc functions with GFP_ATOMIC)
With PF_MEMALLOC flag set in the current->flags, the VM subsystem avoids
any watermark checks before allocating memory thus guarantee'ing the
memory till the last free page. Further, looking at the code in
mm/page_alloc.c in __alloc_pages() function, looks like this
flag is useful only in the non-interrupt context.
If we are in the interrupt context and memory allocation in IOMMU
driver fails for some reason, then the DMA map api's will return
failure and it is up to the higher level drivers to retry. Suppose,
if upper level driver programs the controller with the buggy
DMA virtual address, the IOMMU will block that DMA transaction
when that happens thus preventing any corruption to main memory.
So far in our test scenario, we were unable to create
any memory allocation failure inside dma map api calls.
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
---
drivers/pci/intel-iommu.c | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
Index: linux-2.6.22-rc4-mm2/drivers/pci/intel-iommu.c
===================================================================
--- linux-2.6.22-rc4-mm2.orig/drivers/pci/intel-iommu.c 2007-06-18 15:45:46.000000000 -0700
+++ linux-2.6.22-rc4-mm2/drivers/pci/intel-iommu.c 2007-06-19 13:10:29.000000000 -0700
@@ -84,9 +84,31 @@
static struct kmem_cache *iommu_devinfo_cache;
static struct kmem_cache *iommu_iova_cache;
+static inline void *iommu_kmem_cache_alloc(struct kmem_cache *cachep)
+{
+ unsigned int flags;
+ void *vaddr;
+
+ /* trying to avoid low memory issues */
+ flags = current->flags & PF_MEMALLOC;
+ current->flags |= PF_MEMALLOC;
+ vaddr = kmem_cache_alloc(cachep, GFP_ATOMIC);
+ current->flags &= (~PF_MEMALLOC | flags);
+ return vaddr;
+}
+
+
static inline void *alloc_pgtable_page(void)
{
- return (void *)get_zeroed_page(GFP_ATOMIC);
+ unsigned int flags;
+ void *vaddr;
+
+ /* trying to avoid low memory issues */
+ flags = current->flags & PF_MEMALLOC;
+ current->flags |= PF_MEMALLOC;
+ vaddr = (void *)get_zeroed_page(GFP_ATOMIC);
+ current->flags &= (~PF_MEMALLOC | flags);
+ return vaddr;
}
static inline void free_pgtable_page(void *vaddr)
@@ -96,7 +118,7 @@
static inline void *alloc_domain_mem(void)
{
- return kmem_cache_alloc(iommu_domain_cache, GFP_ATOMIC);
+ return iommu_kmem_cache_alloc(iommu_domain_cache);
}
static inline void free_domain_mem(void *vaddr)
@@ -106,7 +128,7 @@
static inline void * alloc_devinfo_mem(void)
{
- return kmem_cache_alloc(iommu_devinfo_cache, GFP_ATOMIC);
+ return iommu_kmem_cache_alloc(iommu_devinfo_cache);
}
static inline void free_devinfo_mem(void *vaddr)
@@ -116,7 +138,7 @@
struct iova *alloc_iova_mem(void)
{
- return kmem_cache_alloc(iommu_iova_cache, GFP_ATOMIC);
+ return iommu_kmem_cache_alloc(iommu_iova_cache);
}
void free_iova_mem(struct iova *iova)
--
next prev parent reply other threads:[~2007-06-19 22:19 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-19 21:37 [Intel IOMMU 00/10] Intel IOMMU support, take #2 Keshavamurthy, Anil S
2007-06-19 21:37 ` [Intel IOMMU 01/10] DMAR detection and parsing logic Keshavamurthy, Anil S
2007-07-04 9:18 ` Peter Zijlstra
2007-07-04 10:04 ` Andrew Morton
2007-07-04 10:14 ` Peter Zijlstra
2007-06-19 21:37 ` [Intel IOMMU 02/10] PCI generic helper function Keshavamurthy, Anil S
2007-06-26 5:49 ` Andrew Morton
2007-06-26 14:44 ` Keshavamurthy, Anil S
2007-06-19 21:37 ` [Intel IOMMU 03/10] clflush_cache_range now takes size param Keshavamurthy, Anil S
2007-06-19 21:37 ` [Intel IOMMU 04/10] IOVA allocation and management routines Keshavamurthy, Anil S
2007-06-26 6:07 ` Andrew Morton
2007-06-26 16:16 ` Keshavamurthy, Anil S
2007-06-19 21:37 ` [Intel IOMMU 05/10] Intel IOMMU driver Keshavamurthy, Anil S
2007-06-19 23:32 ` Christoph Lameter
2007-06-19 23:50 ` Keshavamurthy, Anil S
2007-06-19 23:56 ` Christoph Lameter
2007-06-26 6:32 ` Andrew Morton
2007-06-26 16:29 ` Keshavamurthy, Anil S
2007-06-26 6:25 ` Andrew Morton
2007-06-26 16:33 ` Keshavamurthy, Anil S
2007-06-26 6:30 ` Andrew Morton
2007-06-19 21:37 ` Keshavamurthy, Anil S [this message]
2007-06-19 23:25 ` [Intel IOMMU 06/10] Avoid memory allocation failures in dma map api calls Christoph Lameter
2007-06-19 23:27 ` Arjan van de Ven
2007-06-19 23:34 ` Christoph Lameter
2007-06-20 0:02 ` Arjan van de Ven
2007-06-20 8:06 ` Peter Zijlstra
2007-06-20 13:03 ` Arjan van de Ven
2007-06-20 17:30 ` Siddha, Suresh B
2007-06-20 18:05 ` Peter Zijlstra
2007-06-20 19:14 ` Arjan van de Ven
2007-06-20 20:08 ` Peter Zijlstra
2007-06-20 23:03 ` Keshavamurthy, Anil S
2007-06-21 6:10 ` Peter Zijlstra
2007-06-21 6:11 ` Arjan van de Ven
2007-06-21 6:29 ` Peter Zijlstra
2007-06-21 6:37 ` Keshavamurthy, Anil S
2007-06-21 7:13 ` Peter Zijlstra
2007-06-21 19:51 ` Keshavamurthy, Anil S
2007-06-21 6:30 ` Keshavamurthy, Anil S
2007-06-26 5:34 ` Andrew Morton
2007-06-19 21:37 ` [Intel IOMMU 07/10] Intel iommu cmdline option - forcedac Keshavamurthy, Anil S
2007-06-19 21:37 ` [Intel IOMMU 08/10] DMAR fault handling support Keshavamurthy, Anil S
2007-06-19 21:37 ` [Intel IOMMU 09/10] Iommu Gfx workaround Keshavamurthy, Anil S
2007-06-19 21:37 ` [Intel IOMMU 10/10] Iommu floppy workaround Keshavamurthy, Anil S
2007-06-26 6:42 ` Andrew Morton
2007-06-26 10:37 ` Andi Kleen
2007-06-26 19:25 ` Keshavamurthy, Anil S
2007-06-26 16:26 ` Keshavamurthy, Anil S
2007-06-26 6:45 ` [Intel IOMMU 00/10] Intel IOMMU support, take #2 Andrew Morton
2007-06-26 7:12 ` Andi Kleen
2007-06-26 11:13 ` Muli Ben-Yehuda
2007-06-26 15:03 ` Arjan van de Ven
2007-06-26 15:11 ` Muli Ben-Yehuda
2007-06-26 15:48 ` Keshavamurthy, Anil S
2007-06-26 16:00 ` Muli Ben-Yehuda
2007-06-26 15:56 ` Andi Kleen
2007-06-26 15:09 ` Muli Ben-Yehuda
2007-06-26 15:36 ` Andi Kleen
2007-06-26 15:15 ` Arjan van de Ven
2007-06-26 15:33 ` Andi Kleen
2007-06-26 16:25 ` Arjan van de Ven
2007-06-26 17:31 ` Andi Kleen
2007-06-26 20:10 ` Jesse Barnes
2007-06-26 22:35 ` Andi Kleen
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=20070619213808.798646000@askeshav-devel.jf.intel.com \
--to=anil.s.keshavamurthy@intel.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=clameter@sgi.com \
--cc=davem@davemloft.net \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@il.ibm.com \
--cc=suresh.b.siddha@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®