1. 04 1月, 2009 1 次提交
  2. 03 1月, 2009 1 次提交
    • R
      swiotlb: add missing __init annotations · 79ff56eb
      Roland Dreier 提交于
      Impact: cleanup, reduce kernel size a bit
      
      The current kernel build warns:
      
          WARNING: vmlinux.o(.text+0x11458): Section mismatch in reference from the function swiotlb_alloc_boot() to the function .init.text:__alloc_bootmem_low()
          The function swiotlb_alloc_boot() references
          the function __init __alloc_bootmem_low().
          This is often because swiotlb_alloc_boot lacks a __init
          annotation or the annotation of __alloc_bootmem_low is wrong.
      
          WARNING: vmlinux.o(.text+0x1011f2): Section mismatch in reference from the function swiotlb_late_init_with_default_size() to the function .init.text:__alloc_bootmem_low()
          The function swiotlb_late_init_with_default_size() references
          the function __init __alloc_bootmem_low().
          This is often because swiotlb_late_init_with_default_size lacks a __init
          annotation or the annotation of __alloc_bootmem_low is wrong.
      
      and indeed the functions calling __alloc_bootmem_low() can be marked
      __init as well.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      79ff56eb
  3. 18 12月, 2008 6 次提交
  4. 17 12月, 2008 2 次提交
  5. 17 11月, 2008 1 次提交
    • F
      swiotlb: use coherent_dma_mask in alloc_coherent · 1e74f300
      FUJITA Tomonori 提交于
      Impact: fix DMA buffer allocation coherency bug in certain configs
      
      This patch fixes swiotlb to use dev->coherent_dma_mask in
      swiotlb_alloc_coherent().
      
      coherent_dma_mask is a subset of dma_mask (equal to it most of
      the time), enumerating the address range that a given device
      is able to DMA to/from in a cache-coherent way.
      
      But currently, swiotlb uses dev->dma_mask in alloc_coherent()
      implicitly via address_needs_mapping(), but alloc_coherent is really
      supposed to use coherent_dma_mask.
      
      This bug could break drivers that uses smaller coherent_dma_mask than
      dma_mask (though the current code works for the majority that use the
      same mask for coherent_dma_mask and dma_mask).
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: tony.luck@intel.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1e74f300
  6. 24 10月, 2008 1 次提交
  7. 19 9月, 2008 1 次提交
  8. 11 9月, 2008 1 次提交
    • D
      swiotlb: fix back-off path when memory allocation fails · 36223a39
      Daniel J Blueman 提交于
      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:
       [<ffffffff802b7cf0>] __alloc_pages_internal+0x4a0/0x5d0
       [<ffffffff802d5ddd>] alloc_pages_current+0xad/0x110
       [<ffffffff802b4ccd>] __get_free_pages+0x1d/0x60
       [<ffffffff8046cd39>] swiotlb_alloc_coherent+0x49/0x180
       [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310
       [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90
       [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40
       [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo]
       [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo]
       [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo]
       [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo]
       [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
       [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
       [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev]
       [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo]
       [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30
       [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo]
       [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32]
       [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32]
       [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0
       [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0
       [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0
       [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
       [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c
       [<ffffffff806a6fce>] ? 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: [<ffffffff8046c84c>] 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:[<ffffffff8046c84c>]  [<ffffffff8046c84c>] 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:
       [<ffffffff8046cbb0>] swiotlb_map_single_attrs+0x60/0xf0
       [<ffffffff8046cc4c>] swiotlb_map_single+0xc/0x10
       [<ffffffff8046cdee>] swiotlb_alloc_coherent+0xfe/0x180
       [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310
       [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90
       [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40
       [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo]
       [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo]
       [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo]
       [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo]
       [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
       [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
       [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev]
       [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo]
       [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30
       [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo]
       [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32]
       [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32]
       [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0
       [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0
       [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0
       [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
       [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c
       [<ffffffff806a6fce>] ? 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  [<ffffffff8046c84c>] map_single+0x1c/0x280
       RSP <ffff88010e78d988>
      CR2: 00000000000002c8
      ---[ end trace 5d15baeeb7025a0e ]---
      
       --- [3]
      
      ffffffff8046c830 <map_single>:
      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: NDaniel J Blueman <daniel.blueman@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      36223a39
  9. 10 9月, 2008 1 次提交
  10. 08 9月, 2008 4 次提交
  11. 27 7月, 2008 1 次提交
    • F
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori 提交于
      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: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Avi Kivity <avi@qumranet.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  12. 29 4月, 2008 3 次提交
  13. 14 3月, 2008 1 次提交
    • J
      avoid endless loops in lib/swiotlb.c · b15a3891
      Jan Beulich 提交于
      Commit 681cc5cd ("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: NJan Beulich <jbeulich@novell.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b15a3891
  14. 06 2月, 2008 1 次提交
  15. 23 10月, 2007 1 次提交
  16. 17 10月, 2007 1 次提交
  17. 16 10月, 2007 1 次提交
  18. 13 10月, 2007 1 次提交
  19. 22 7月, 2007 1 次提交
  20. 09 5月, 2007 1 次提交
  21. 07 3月, 2007 1 次提交
  22. 13 2月, 2007 1 次提交
    • A
      [PATCH] swiotlb uninlinings · be6b0267
      Andrew Morton 提交于
      Optimise swiotlb.c for size.
      
         text    data     bss     dec     hex filename
         5009      89      64    5162    142a lib/swiotlb.o-before
         4666      89      64    4819    12d3 lib/swiotlb.o-after
      
      For some reason my gcc (4.0.2) doesn't want to tailcall these things.
      
      swiotlb_sync_sg_for_device:
      	pushq	%rbp	#
      	movl	$1, %r8d	#,
      	movq	%rsp, %rbp	#,
      	call	swiotlb_sync_sg	#
      	leave
      	ret
      	.size	swiotlb_sync_sg_for_device, .-swiotlb_sync_sg_for_device
      	.section	.text.swiotlb_sync_sg_for_cpu,"ax",@progbits
      .globl swiotlb_sync_sg_for_cpu
      	.type	swiotlb_sync_sg_for_cpu, @function
      swiotlb_sync_sg_for_cpu:
      	pushq	%rbp	#
      	xorl	%r8d, %r8d	#
      	movq	%rsp, %rbp	#,
      	call	swiotlb_sync_sg	#
      	leave
      	ret
      
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      be6b0267
  23. 06 2月, 2007 4 次提交
  24. 25 3月, 2006 1 次提交
  25. 12 1月, 2006 1 次提交
    • M
      [PATCH] x86_64: Use function pointers to call DMA mapping functions · 17a941d8
      Muli Ben-Yehuda 提交于
      AK: I hacked Muli's original patch a lot and there were a lot
      of changes - all bugs are probably to blame on me now.
      There were also some changes in the fall back behaviour
      for swiotlb - in particular it doesn't try to use GFP_DMA
      now anymore. Also all DMA mapping operations use the
      same core dma_alloc_coherent code with proper fallbacks now.
      And various other changes and cleanups.
      
      Known problems: iommu=force swiotlb=force together breaks
                      needs more testing.
      
      This patch cleans up x86_64's DMA mapping dispatching code. Right now
      we have three possible IOMMU types: AGP GART, swiotlb and nommu, and
      in the future we will also have Xen's x86_64 swiotlb and other HW
      IOMMUs for x86_64. In order to support all of them cleanly, this
      patch:
      
      - introduces a struct dma_mapping_ops with function pointers for each
        of the DMA mapping operations of gart (AMD HW IOMMU), swiotlb
        (software IOMMU) and nommu (no IOMMU).
      
      - gets rid of:
      
        if (swiotlb)
            return swiotlb_xxx();
      
      - PCI_DMA_BUS_IS_PHYS is now checked against the dma_ops being set
      This makes swiotlb faster by avoiding double copying in some cases.
      Signed-Off-By: NMuli Ben-Yehuda <mulix@mulix.org>
      Signed-Off-By: NJon D. Mason <jdmason@us.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      17a941d8
  26. 07 1月, 2006 1 次提交