linux-toradex.git/lib/swiotlb.c, branch v2.6.27.30

swiotlb: fix back-off path when memory allocation fails

2008-09-10T21:00:23+00:00

This fixes a SWIOTLB oops

With SWIOTLB being enabled and straight-forward page allocation
failure [1], the swiotlb_alloc_coherent fall-back path hits an
issue [2], resulting in my webcam failing to work.

At the time of oops, RDI is clearly a pointer to a structure which
has arrived as NULL, leading to the typo in swiotlb_map_single's
callsite arguments.

Correctly passing the device structure [3] addresses the issue and
gets my webcam working again (the allocation failure still occuring).

 --- [1]

skype: page allocation failure. order:3, mode:0x1
Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1

Call Trace:
 [] __alloc_pages_internal+0x4a0/0x5d0
 [] alloc_pages_current+0xad/0x110
 [] __get_free_pages+0x1d/0x60
 [] swiotlb_alloc_coherent+0x49/0x180
 [] dma_alloc_coherent+0x281/0x310
 [] hcd_buffer_alloc+0x50/0x90
 [] usb_buffer_alloc+0x2d/0x40
 [] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo]
 [] uvc_init_video+0x158/0x3e0 [uvcvideo]
 [] uvc_video_enable+0x37/0x80 [uvcvideo]
 [] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo]
 [] ? trace_hardirqs_off_caller+0x21/0xc0
 [] ? trace_hardirqs_off_caller+0x21/0xc0
 [] video_usercopy+0x19f/0x390 [videodev]
 [] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo]
 [] ? put_lock_stats+0xe/0x30
 [] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo]
 [] native_ioctl+0x83/0x90 [compat_ioctl32]
 [] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32]
 [] ? do_page_fault+0x3d1/0xae0
 [] ? trace_hardirqs_on+0xd/0x10
 [] ? trace_hardirqs_on_caller+0x149/0x1b0
 [] ? trace_hardirqs_on+0xd/0x10
 [] compat_sys_ioctl+0x8a/0x3c0
 [] ? trace_hardirqs_off_thunk+0x3a/0x3c
 [] sysenter_dispatch+0x7/0x2c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f

Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:   3
CPU    1: hi:  186, btch:  31 usd:   0
Node 0 Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd:  23
CPU    1: hi:  186, btch:  31 usd: 179
Active:78545 inactive:48683 dirty:31 writeback:0 unstable:2
 free:830202 slab:17516 mapped:17473 pagetables:3496 bounce:0
Node 0 DMA free:36kB min:28kB low:32kB high:40kB active:0kB
inactive:0kB present:15156kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 3207 3956 3956
Node 0 DMA32 free:3197192kB min:6512kB low:8140kB high:9768kB
active:0kB inactive:0kB present:3284896kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0 748 748
Node 0 Normal free:123580kB min:1516kB low:1892kB high:2272kB
active:314180kB inactive:194732kB present:766464kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 36kB
Node 0 DMA32: 4*4kB 3*8kB 2*16kB 3*32kB 4*64kB 5*128kB 3*256kB 5*512kB
4*1024kB 5*2048kB 776*4096kB = 3197224kB
Node 0 Normal: 14*4kB 14*8kB 8*16kB 6*32kB 1*64kB 3*128kB 3*256kB
2*512kB 4*1024kB 1*2048kB 28*4096kB = 123560kB
64847 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 502752kB
Total swap = 502752kB
1048576 pages RAM
52120 pages reserved
71967 pages shared
143004 pages non-shared

 --- [2]

BUG: unable to handle kernel NULL pointer dereference at 00000000000002c8
IP: [] map_single+0x1c/0x280
PGD 10e54e067 PUD 10e595067 PMD 0
Oops: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: kvm_intel kvm microcode uvcvideo compat_ioctl32
videodev v4l1_compat shpchp pci_hotplug
Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1
RIP: 0010:[]  [] map_single+0x1c/0x280
RSP: 0018:ffff88010e78d988  EFLAGS: 00210296
RAX: 0000780000000000 RBX: 0000000000000000 RCX: 0000000000000002
RDX: 0000000000005000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88010e78d9e8 R08: 0000000000000000 R09: 0000000000000001
R10: ffff88010e78d698 R11: 0000000000000001 R12: 0000000000000002
R13: 0000000000000000 R14: 0000000000005000 R15: ffff88012f1c9968
FS:  0000000000000000(0000) GS:ffffffff80a6cdc0(0063) knlGS:00000000f6355b90
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000000002c8 CR3: 000000010e57d000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process skype (pid: 5895, threadinfo ffff88010e78c000, task ffff88012b9cc460)
Stack:  0000000200000000 0000000000005000 0000000000000000 0000000000000000
 00000000000017b8 0000000000000000 ffff88010e78d9c8 0000000000000000
 0000000000000002 0000000000000000 0000000000005000 ffff88012f1c9968
Call Trace:
 [] swiotlb_map_single_attrs+0x60/0xf0
 [] swiotlb_map_single+0xc/0x10
 [] swiotlb_alloc_coherent+0xfe/0x180
 [] dma_alloc_coherent+0x281/0x310
 [] hcd_buffer_alloc+0x50/0x90
 [] usb_buffer_alloc+0x2d/0x40
 [] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo]
 [] uvc_init_video+0x158/0x3e0 [uvcvideo]
 [] uvc_video_enable+0x37/0x80 [uvcvideo]
 [] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo]
 [] ? trace_hardirqs_off_caller+0x21/0xc0
 [] ? trace_hardirqs_off_caller+0x21/0xc0
 [] video_usercopy+0x19f/0x390 [videodev]
 [] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo]
 [] ? put_lock_stats+0xe/0x30
 [] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo]
 [] native_ioctl+0x83/0x90 [compat_ioctl32]
 [] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32]
 [] ? do_page_fault+0x3d1/0xae0
 [] ? trace_hardirqs_on+0xd/0x10
 [] ? trace_hardirqs_on_caller+0x149/0x1b0
 [] ? trace_hardirqs_on+0xd/0x10
 [] compat_sys_ioctl+0x8a/0x3c0
 [] ? trace_hardirqs_off_thunk+0x3a/0x3c
 [] sysenter_dispatch+0x7/0x2c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f

Code: 45 31 c0 48 89 e5 e8 a4 ff ff ff c9 c3 66 90 55 48 89 e5 41 57
41 56 41 55 41 54 53 48 83 ec 38 48 89 75 b0 48 89 55 a8 89 4d a4 <48>
8b 87 c8 02 00 00 48 85 c0 0f 84 1c 02 00 00 48 8b 58 08 48
RIP  [] map_single+0x1c/0x280
 RSP 
CR2: 00000000000002c8
---[ end trace 5d15baeeb7025a0e ]---

 --- [3]

ffffffff8046c830 :
map_single():
/store/kernel/linux/lib/swiotlb.c:291
ffffffff8046c830:       55                      push   %rbp
ffffffff8046c831:       48 89 e5                mov    %rsp,%rbp
ffffffff8046c834:       41 57                   push   %r15
ffffffff8046c836:       41 56                   push   %r14
ffffffff8046c838:       41 55                   push   %r13
ffffffff8046c83a:       41 54                   push   %r12
ffffffff8046c83c:       53                      push   %rbx
ffffffff8046c83d:       48 83 ec 38             sub    $0x38,%rsp
ffffffff8046c841:       48 89 75 b0             mov    %rsi,-0x50(%rbp)
ffffffff8046c845:       48 89 55 a8             mov    %rdx,-0x58(%rbp)
ffffffff8046c849:       89 4d a4                mov    %ecx,-0x5c(%rbp)
dma_get_seg_boundary():
/store/kernel/linux/include/linux/dma-mapping.h:80
ffffffff8046c84c:       48 8b 87 c8 02 00 00    mov    0x2c8(%rdi),%rax <----

 --- [4]

Signed-off-by: Daniel J Blueman 
Signed-off-by: Linus Torvalds

dma-mapping: add the device argument to dma_mapping_error()

2008-07-26T19:00:03+00:00

Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
architecture does:

This enables us to cleanly fix the Calgary IOMMU issue that some devices
are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).

I think that per-device dma_mapping_ops support would be also helpful for
KVM people to support PCI passthrough but Andi thinks that this makes it
difficult to support the PCI passthrough (see the above thread).  So I
CC'ed this to KVM camp.  Comments are appreciated.

A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
NULL, the system-wide dma_ops pointer is used as before.

If it's useful for KVM people, I plan to implement a mechanism to register
a hook called when a new pci (or dma capable) device is created (it works
with hot plugging).  It enables IOMMUs to set up an appropriate
dma_mapping_ops per device.

The major obstacle is that dma_mapping_error doesn't take a pointer to the
device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
device.  Note all the POWER IOMMUs use the same dma_mapping_error function
so this is not a problem for POWER but x86 IOMMUs use different
dma_mapping_error functions.

The first patch adds the device argument to dma_mapping_error.  The patch
is trivial but large since it touches lots of drivers and dma-mapping.h in
all the architecture.

This patch:

dma_mapping_error() doesn't take a pointer to the device unlike other DMA
operations.  So we can't have dma_mapping_ops per device.

Note that POWER already has dma_mapping_ops per device but all the POWER
IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
argument.

[akpm@linux-foundation.org: fix sge]
[akpm@linux-foundation.org: fix svc_rdma]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix bnx2x]
[akpm@linux-foundation.org: fix s2io]
[akpm@linux-foundation.org: fix pasemi_mac]
[akpm@linux-foundation.org: fix sdhci]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix sparc]
[akpm@linux-foundation.org: fix ibmvscsi]
Signed-off-by: FUJITA Tomonori 
Cc: Muli Ben-Yehuda 
Cc: Andi Kleen 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Avi Kivity 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dma/ia64: update ia64 machvecs, swiotlb.c

2008-04-29T15:06:12+00:00

Change all ia64 machvecs to use the new dma_*map*_attrs() interfaces.
Implement the old dma_*map_*() interfaces in terms of the corresponding new
interfaces.  For ia64/sn, make use of one dma attribute,
DMA_ATTR_WRITE_BARRIER.  Introduce swiotlb_*map*_attrs() functions.

Signed-off-by: Arthur Kepner 
Cc: Tony Luck 
Cc: Jesse Barnes 
Cc: Jes Sorensen 
Cc: Randy Dunlap 
Cc: Roland Dreier 
Cc: James Bottomley 
Cc: David Miller 
Cc: Benjamin Herrenschmidt 
Cc: Grant Grundler 
Cc: Michael Ellerman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

swiotlb: use iommu_is_span_boundary helper function

2008-04-29T15:06:05+00:00

iommu_is_span_boundary in lib/iommu-helper.c was exported for PARISC IOMMUs
(commit 3715863aa142c4f4c5208f5f3e5e9bac06006d2f).  SWIOTLB can use it instead
of the homegrown function.

Signed-off-by: FUJITA Tomonori 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Tony Luck 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/swiotlb.c: cleanups

2008-04-29T15:06:05+00:00

There's a pointlessly braced block of code in there.  Remove the braces and
save a tabstop.

Cc: Andi Kleen 
Cc: FUJITA Tomonori 
Cc: Jan Beulich 
Cc: Tony Luck 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

avoid endless loops in lib/swiotlb.c

2008-03-13T20:15:52+00:00

Commit 681cc5cd3efbeafca6386114070e0bfb5012e249 ("iommu sg merging:
swiotlb: respect the segment boundary limits") introduced two
possibilities for entering an endless loop in lib/swiotlb.c:

 - if max_slots is zero (possible if mask is ~0UL)
 - if the number of slots requested fits into a swiotlb segment, but is
   too large for the part of a segment which remains after considering
   offset_slots

This fixes them

Signed-off-by: Jan Beulich 
Cc: FUJITA Tomonori 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds

iommu sg merging: swiotlb: respect the segment boundary limits

2008-02-05T17:44:12+00:00

This patch makes swiotlb not allocate a memory area spanning LLD's segment
boundary.

is_span_boundary() judges whether a memory area spans LLD's segment boundary.
If map_single finds such a area, map_single tries to find the next available
memory area.

Signed-off-by: FUJITA Tomonori 
Cc: James Bottomley 
Cc: Jens Axboe 
Cc: Greg KH 
Cc: Jeff Garzik 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Update swiotlb to use sg helpers

2007-10-22T19:19:58+00:00

Signed-off-by: Jens Axboe

swiotlb: fix map_sg failure handling

2007-10-17T08:06:18+00:00

sg list elements might not be continuous.

Signed-off-by: FUJITA Tomonori 
Signed-off-by: Jens Axboe

swiotlb: sg chaining support

2007-10-16T09:26:01+00:00

Signed-off-by: Jens Axboe