Commit 712b0006 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip 

* 'iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (60 commits)
  dma-debug: make memory range checks more consistent
  dma-debug: warn of unmapping an invalid dma address
  dma-debug: fix dma_debug_add_bus() definition for !CONFIG_DMA_API_DEBUG
  dma-debug/x86: register pci bus for dma-debug leak detection
  dma-debug: add a check dma memory leaks
  dma-debug: add checks for kernel text and rodata
  dma-debug: print stacktrace of mapping path on unmap error
  dma-debug: Documentation update
  dma-debug: x86 architecture bindings
  dma-debug: add function to dump dma mappings
  dma-debug: add checks for sync_single_sg_*
  dma-debug: add checks for sync_single_range_*
  dma-debug: add checks for sync_single_*
  dma-debug: add checking for [alloc|free]_coherent
  dma-debug: add add checking for map/unmap_sg
  dma-debug: add checking for map/unmap_page/single
  dma-debug: add core checking functions
  dma-debug: add debugfs interface
  dma-debug: add kernel command line parameters
  dma-debug: add initialization code
  ...

Fix trivial conflicts due to whitespace changes in arch/x86/kernel/pci-nommu.c
parents e1c50248 b0d44c0d

Documentation/DMA-API.txt

+106 −0
Original line number Diff line number Diff line
@@ -609,3 +609,109 @@ size is the size (and should be a page-sized multiple). 
The return value will be either a pointer to the processor virtual

address of the memory, or an error (via PTR_ERR()) if any part of the

region is occupied.



Part III - Debug drivers use of the DMA-API

-------------------------------------------



The DMA-API as described above as some constraints. DMA addresses must be

released with the corresponding function with the same size for example. With

the advent of hardware IOMMUs it becomes more and more important that drivers

do not violate those constraints. In the worst case such a violation can

result in data corruption up to destroyed filesystems.



To debug drivers and find bugs in the usage of the DMA-API checking code can

be compiled into the kernel which will tell the developer about those

violations. If your architecture supports it you can select the "Enable

debugging of DMA-API usage" option in your kernel configuration. Enabling this

option has a performance impact. Do not enable it in production kernels.



If you boot the resulting kernel will contain code which does some bookkeeping

about what DMA memory was allocated for which device. If this code detects an

error it prints a warning message with some details into your kernel log. An

example warning message may look like this:



------------[ cut here ]------------

WARNING: at /data2/repos/linux-2.6-iommu/lib/dma-debug.c:448

	check_unmap+0x203/0x490()

Hardware name:

forcedeth 0000:00:08.0: DMA-API: device driver frees DMA memory with wrong

	function [device address=0x00000000640444be] [size=66 bytes] [mapped as

single] [unmapped as page]

Modules linked in: nfsd exportfs bridge stp llc r8169

Pid: 0, comm: swapper Tainted: G        W  2.6.28-dmatest-09289-g8bb99c0 #1

Call Trace:

 <IRQ>  [<ffffffff80240b22>] warn_slowpath+0xf2/0x130

 [<ffffffff80647b70>] _spin_unlock+0x10/0x30

 [<ffffffff80537e75>] usb_hcd_link_urb_to_ep+0x75/0xc0

 [<ffffffff80647c22>] _spin_unlock_irqrestore+0x12/0x40

 [<ffffffff8055347f>] ohci_urb_enqueue+0x19f/0x7c0

 [<ffffffff80252f96>] queue_work+0x56/0x60

 [<ffffffff80237e10>] enqueue_task_fair+0x20/0x50

 [<ffffffff80539279>] usb_hcd_submit_urb+0x379/0xbc0

 [<ffffffff803b78c3>] cpumask_next_and+0x23/0x40

 [<ffffffff80235177>] find_busiest_group+0x207/0x8a0

 [<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50

 [<ffffffff803c7ea3>] check_unmap+0x203/0x490

 [<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50

 [<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0

 [<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0

 [<ffffffff8026df84>] handle_IRQ_event+0x34/0x70

 [<ffffffff8026ffe9>] handle_edge_irq+0xc9/0x150

 [<ffffffff8020e3ab>] do_IRQ+0xcb/0x1c0

 [<ffffffff8020c093>] ret_from_intr+0x0/0xa

 <EOI> <4>---[ end trace f6435a98e2a38c0e ]---



The driver developer can find the driver and the device including a stacktrace

of the DMA-API call which caused this warning.



Per default only the first error will result in a warning message. All other

errors will only silently counted. This limitation exist to prevent the code

from flooding your kernel log. To support debugging a device driver this can

be disabled via debugfs. See the debugfs interface documentation below for

details.



The debugfs directory for the DMA-API debugging code is called dma-api/. In

this directory the following files can currently be found:



	dma-api/all_errors	This file contains a numeric value. If this

				value is not equal to zero the debugging code

				will print a warning for every error it finds

				into the kernel log. Be carefull with this

				option. It can easily flood your logs.



	dma-api/disabled	This read-only file contains the character 'Y'

				if the debugging code is disabled. This can

				happen when it runs out of memory or if it was

				disabled at boot time



	dma-api/error_count	This file is read-only and shows the total

				numbers of errors found.



	dma-api/num_errors	The number in this file shows how many

				warnings will be printed to the kernel log

				before it stops. This number is initialized to

				one at system boot and be set by writing into

				this file



	dma-api/min_free_entries

				This read-only file can be read to get the

				minimum number of free dma_debug_entries the

				allocator has ever seen. If this value goes

				down to zero the code will disable itself

				because it is not longer reliable.



	dma-api/num_free_entries

				The current number of free dma_debug_entries

				in the allocator.



If you have this code compiled into your kernel it will be enabled by default.

If you want to boot without the bookkeeping anyway you can provide

'dma_debug=off' as a boot parameter. This will disable DMA-API debugging.

Notice that you can not enable it again at runtime. You have to reboot to do

so.



When the code disables itself at runtime this is most likely because it ran

out of dma_debug_entries. These entries are preallocated at boot. The number

of preallocated entries is defined per architecture. If it is too low for you

boot with 'dma_debug_entries=<your_desired_number>' to overwrite the

architectural default.

Documentation/kernel-parameters.txt

+10 −0
Original line number Diff line number Diff line
@@ -492,6 +492,16 @@ and is between 256 and 4096 characters. It is defined in the file 
			Range: 0 - 8192

			Default: 64



	dma_debug=off	If the kernel is compiled with DMA_API_DEBUG support

			this option disables the debugging code at boot.



	dma_debug_entries=<number>

			This option allows to tune the number of preallocated

			entries for DMA-API debugging code. One entry is

			required per DMA-API allocation. Use this if the

			DMA-API debugging code disables itself because the

			architectural default is too low.



	hpet=		[X86-32,HPET] option to control HPET usage

			Format: { enable (default) | disable | force |

				verbose }

arch/Kconfig

+2 −0
Original line number Diff line number Diff line
@@ -106,3 +106,5 @@ config HAVE_CLK 
	  The <linux/clk.h> calls support software clock gating and

	  thus are a key power management tool on many systems.



config HAVE_DMA_API_DEBUG

	bool

arch/ia64/dig/Makefile

+2 −2
Original line number Diff line number Diff line
@@ -7,8 +7,8 @@ 


obj-y := setup.o

ifeq ($(CONFIG_DMAR), y)

obj-$(CONFIG_IA64_GENERIC) += machvec.o machvec_vtd.o dig_vtd_iommu.o

obj-$(CONFIG_IA64_GENERIC) += machvec.o machvec_vtd.o

else

obj-$(CONFIG_IA64_GENERIC) += machvec.o

endif

obj-$(CONFIG_IA64_DIG_VTD) += dig_vtd_iommu.o

arch/ia64/dig/dig_vtd_iommu.c

deleted100644 → 0
+0 −59
Original line number Diff line number Diff line 
#include <linux/types.h>

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/intel-iommu.h>



void *

vtd_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle,

		 gfp_t flags)

{

	return intel_alloc_coherent(dev, size, dma_handle, flags);

}

EXPORT_SYMBOL_GPL(vtd_alloc_coherent);



void

vtd_free_coherent(struct device *dev, size_t size, void *vaddr,

		 dma_addr_t dma_handle)

{

	intel_free_coherent(dev, size, vaddr, dma_handle);

}

EXPORT_SYMBOL_GPL(vtd_free_coherent);



dma_addr_t

vtd_map_single_attrs(struct device *dev, void *addr, size_t size,

		     int dir, struct dma_attrs *attrs)

{

	return intel_map_single(dev, (phys_addr_t)addr, size, dir);

}

EXPORT_SYMBOL_GPL(vtd_map_single_attrs);



void

vtd_unmap_single_attrs(struct device *dev, dma_addr_t iova, size_t size,

		       int dir, struct dma_attrs *attrs)

{

	intel_unmap_single(dev, iova, size, dir);

}

EXPORT_SYMBOL_GPL(vtd_unmap_single_attrs);



int

vtd_map_sg_attrs(struct device *dev, struct scatterlist *sglist, int nents,

		 int dir, struct dma_attrs *attrs)

{

	return intel_map_sg(dev, sglist, nents, dir);

}

EXPORT_SYMBOL_GPL(vtd_map_sg_attrs);



void

vtd_unmap_sg_attrs(struct device *dev, struct scatterlist *sglist,

		   int nents, int dir, struct dma_attrs *attrs)

{

	intel_unmap_sg(dev, sglist, nents, dir);

}

EXPORT_SYMBOL_GPL(vtd_unmap_sg_attrs);



int

vtd_dma_mapping_error(struct device *dev, dma_addr_t dma_addr)

{

	return 0;

}

EXPORT_SYMBOL_GPL(vtd_dma_mapping_error);

CRA Git | Maintained and supported by SUSTech CRA and CCSE