Merge master.kernel.org:/home/davem/BK/misc-2.5

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

Documentation/DMA-mapping.txt

@@ -8,7 +8,7 @@
 Most of the 64bit platforms have special hardware that translates bus
 addresses (DMA addresses) into physical addresses.  This is similar to
 how page tables and/or a TLB translates virtual addresses to physical
-addresses on a cpu.  This is needed so that e.g. PCI devices can
+addresses on a CPU.  This is needed so that e.g. PCI devices can
 access with a Single Address Cycle (32bit DMA address) any page in the
 64bit physical address space.  Previously in Linux those 64bit
 platforms had to set artificial limits on the maximum RAM size in the
@@ -37,7 +37,7 @@ returned from the DMA mapping functions.
 			 What memory is DMA'able?
 
 The first piece of information you must know is what kernel memory can
-be used with the DMA mapping facilitites.  There has been an unwritten
+be used with the DMA mapping facilities.  There has been an unwritten
 set of rules regarding this, and this text is an attempt to finally
 write them down.
 
@@ -106,7 +106,7 @@ This means that in the failure case, you have three options:
 3) Ignore this device and do not initialize it.
 
 It is recommended that your driver print a kernel KERN_WARNING message
-when you end up performing either #2 or #2.  In this manner, if a user
+when you end up performing either #2 or #3.  In this manner, if a user
 of your driver reports that performance is bad or that the device is not
 even detected, you can ask them for the kernel messages to find out
 exactly why.
@@ -146,7 +146,7 @@ all 64-bits during a DAC cycle:
 If your 64-bit device is going to be an enormous consumer of DMA
 mappings, this can be problematic since the DMA mappings are a
 finite resource on many platforms.  Please see the "DAC Addressing
-for Address Space Hungry Devices" setion near the end of this
+for Address Space Hungry Devices" section near the end of this
 document for how to handle this case.
 
 Finally, if your device can only drive the low 24-bits of
@@ -205,7 +205,7 @@ There are two types of DMA mappings:
 
 - Consistent DMA mappings which are usually mapped at driver
   initialization, unmapped at the end and for which the hardware should
-  guarantee that the device and the cpu can access the data
+  guarantee that the device and the CPU can access the data
   in parallel and will see updates made by each other without any
   explicit software flushing.
 
@@ -222,12 +222,12 @@ There are two types of DMA mappings:
 	- Device firmware microcode executed out of
 	  main memory.
 
-  The invariant these examples all require is that any cpu store
+  The invariant these examples all require is that any CPU store
   to memory is immediately visible to the device, and vice
   versa.  Consistent mappings guarantee this.
 
   IMPORTANT: Consistent DMA memory does not preclude the usage of
-             proper memory barriers.  The cpu may reorder stores to
+             proper memory barriers.  The CPU may reorder stores to
 	     consistent memory just as it may normal memory.  Example:
 	     if it is important for the device to see the first word
 	     of a descriptor updated before the second, you must do
@@ -284,7 +284,7 @@ driver needs regions sized smaller than a page, you may prefer using
 the pci_pool interface, described below.
 
 The consistent DMA mapping interfaces, for non-NULL dev, will always
-return a DMA address which is SAC (Single Address Cycle) addressible.
+return a DMA address which is SAC (Single Address Cycle) addressable.
 Even if the device indicates (via PCI dma mask) that it may address
 the upper 32-bits and thus perform DAC cycles, consistent allocation
 will still only return 32-bit PCI addresses for DMA.  This is true
@@ -622,7 +622,7 @@ use the normal APIs without any problems.
 Note that for streaming type mappings you must either use these
 interfaces, or the dynamic mapping interfaces above.  You may not mix
 usage of both for the same device.  Such an act is illegal and is
-guarenteed to put a banana in your tailpipe.
+guaranteed to put a banana in your tailpipe.
 
 However, consistent mappings may in fact be used in conjunction with
 these interfaces.  Remember that, as defined, consistent mappings are
@@ -637,7 +637,7 @@ This routine behaves identically to pci_set_dma_mask.  You may not
 use the following interfaces if this routine fails.
 
 Next, DMA addresses using this API are kept track of using the
-dma64_addr_t type.  It is guarenteed to be big enough to hold any
+dma64_addr_t type.  It is guaranteed to be big enough to hold any
 DAC address the platform layer will give to you from the following
 routines.  If you have consistent mappings as well, you still
 use plain dma_addr_t to keep track of those.
@@ -745,7 +745,7 @@ transform some example code.
 			 PCI_DMA_FROMDEVICE);
 
 It really should be self-explanatory.  We treat the ADDR and LEN
-seperately, because it is possible for an implementation to only
+separately, because it is possible for an implementation to only
 need the address in order to perform the unmap operation.
 
 			Platform Issues

include/asm-i386/pgalloc.h

@@ -223,4 +223,6 @@ static inline void flush_tlb_pgtables(struct mm_struct *mm,
 	/* i386 does not keep any page table caches in TLB */
 }
 
+#define check_pgt_cache()	do { } while (0)
+
 #endif /* _I386_PGALLOC_H */

mm/memory.c

@@ -140,6 +140,9 @@ void clear_page_tables(struct mm_struct *mm, unsigned long first, int nr)
 		page_dir++;
 	} while (--nr);
 	spin_unlock(&mm->page_table_lock);
+
+	/* keep the page table cache within bounds */
+	check_pgt_cache();
 }
 
 pte_t * pte_alloc_map(struct mm_struct *mm, pmd_t *pmd, unsigned long address)