1. 04 Mar, 2014 9 commits
    • Jiang Liu's avatar
      iommu/vt-d: Fix incorrect iommu_count for si_domain · 9ebd682e
      Jiang Liu authored
      The iommu_count field in si_domain(static identity domain) is
      initialized to zero and never increases. It will underflow
      when tearing down iommu unit in function free_dmar_iommu()
      and leak memory. So refine code to correctly manage
      si_domain->iommu_count.
      
      Warning message caused by si_domain memory leak:
      [   14.609681] IOMMU: Setting RMRR:
      [   14.613496] Ignoring identity map for HW passthrough device 0000:00:1a.0 [0xbdcfd000 - 0xbdd1dfff]
      [   14.623809] Ignoring identity map for HW passthrough device 0000:00:1d.0 [0xbdcfd000 - 0xbdd1dfff]
      [   14.634162] IOMMU: Prepare 0-16MiB unity mapping for LPC
      [   14.640329] Ignoring identity map for HW passthrough device 0000:00:1f.0 [0x0 - 0xffffff]
      [   14.673360] IOMMU: dmar init failed
      [   14.678157] kmem_cache_destroy iommu_devinfo: Slab cache still has objects
      [   14.686076] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ #59
      [   14.694176] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
      [   14.707412]  0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff880c2cc37c00
      [   14.716407]  ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00
      [   14.725468]  ffffffff81dc7a6a ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711
      [   14.734464] Call Trace:
      [   14.737453]  [<ffffffff8156223d>] dump_stack+0x4d/0x66
      [   14.743430]  [<ffffffff811790b1>] kmem_cache_destroy+0xf1/0x100
      [   14.750279]  [<ffffffff81dc7a6a>] intel_iommu_init+0x122/0x56a
      [   14.757035]  [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d
      [   14.763491]  [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52
      [   14.769846]  [<ffffffff81000342>] do_one_initcall+0x122/0x180
      [   14.776506]  [<ffffffff81077738>] ? parse_args+0x1e8/0x320
      [   14.782866]  [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c
      [   14.789994]  [<ffffffff81d84833>] ? do_early_param+0x88/0x88
      [   14.796556]  [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0
      [   14.802626]  [<ffffffff8154ffce>] kernel_init+0xe/0x130
      [   14.808698]  [<ffffffff815756ac>] ret_from_fork+0x7c/0xb0
      [   14.814963]  [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0
      [   14.821640] kmem_cache_destroy iommu_domain: Slab cache still has objects
      [   14.829456] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ #59
      [   14.837562] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
      [   14.850803]  0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88102c1ee3c0
      [   14.861222]  ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00
      [   14.870284]  ffffffff81dc7a76 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711
      [   14.879271] Call Trace:
      [   14.882227]  [<ffffffff8156223d>] dump_stack+0x4d/0x66
      [   14.888197]  [<ffffffff811790b1>] kmem_cache_destroy+0xf1/0x100
      [   14.895034]  [<ffffffff81dc7a76>] intel_iommu_init+0x12e/0x56a
      [   14.901781]  [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d
      [   14.908238]  [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52
      [   14.914594]  [<ffffffff81000342>] do_one_initcall+0x122/0x180
      [   14.921244]  [<ffffffff81077738>] ? parse_args+0x1e8/0x320
      [   14.927598]  [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c
      [   14.934738]  [<ffffffff81d84833>] ? do_early_param+0x88/0x88
      [   14.941309]  [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0
      [   14.947380]  [<ffffffff8154ffce>] kernel_init+0xe/0x130
      [   14.953430]  [<ffffffff815756ac>] ret_from_fork+0x7c/0xb0
      [   14.959689]  [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0
      [   14.966299] kmem_cache_destroy iommu_iova: Slab cache still has objects
      [   14.973923] CPU: 12 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ #59
      [   14.982020] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
      [   14.995263]  0000000000000000 ffff88042dd33db0 ffffffff8156223d ffff88042cb5c980
      [   15.004265]  ffff88042dd33dc8 ffffffff811790b1 ffff880c2d3533b8 ffff88042dd33e00
      [   15.013322]  ffffffff81dc7a82 ffffffff81b1e8e0 ffffffff81f84058 ffffffff81d8a711
      [   15.022318] Call Trace:
      [   15.025238]  [<ffffffff8156223d>] dump_stack+0x4d/0x66
      [   15.031202]  [<ffffffff811790b1>] kmem_cache_destroy+0xf1/0x100
      [   15.038038]  [<ffffffff81dc7a82>] intel_iommu_init+0x13a/0x56a
      [   15.044786]  [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d
      [   15.051242]  [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52
      [   15.057601]  [<ffffffff81000342>] do_one_initcall+0x122/0x180
      [   15.064254]  [<ffffffff81077738>] ? parse_args+0x1e8/0x320
      [   15.070608]  [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c
      [   15.077747]  [<ffffffff81d84833>] ? do_early_param+0x88/0x88
      [   15.084300]  [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0
      [   15.090362]  [<ffffffff8154ffce>] kernel_init+0xe/0x130
      [   15.096431]  [<ffffffff815756ac>] ret_from_fork+0x7c/0xb0
      [   15.102693]  [<ffffffff8154ffc0>] ? rest_init+0xd0/0xd0
      [   15.189273] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      9ebd682e
    • Jiang Liu's avatar
      iommu/vt-d: Reduce duplicated code to handle virtual machine domains · 92d03cc8
      Jiang Liu authored
      Reduce duplicated code to handle virtual machine domains, there's no
      functionality changes. It also improves code readability.
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      92d03cc8
    • Jiang Liu's avatar
      iommu/vt-d: Free resources if failed to create domain for PCIe endpoint · e85bb5d4
      Jiang Liu authored
      Enhance function get_domain_for_dev() to release allocated resources
      if failed to create domain for PCIe endpoint, otherwise the allocated
      resources will get lost.
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      e85bb5d4
    • Jiang Liu's avatar
      iommu/vt-d: Simplify function get_domain_for_dev() · 745f2586
      Jiang Liu authored
      Function get_domain_for_dev() is a little complex, simplify it
      by factoring out dmar_search_domain_by_dev_info() and
      dmar_insert_dev_info().
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      745f2586
    • Jiang Liu's avatar
      iommu/vt-d: Move private structures and variables into intel-iommu.c · b94e4117
      Jiang Liu authored
      Move private structures and variables into intel-iommu.c, which will
      help to simplify locking policy for hotplug. Also delete redundant
      declarations.
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      b94e4117
    • Jiang Liu's avatar
      iommu/vt-d: Factor out dmar_alloc_dev_scope() for later reuse · bb3a6b78
      Jiang Liu authored
      Factor out function dmar_alloc_dev_scope() from dmar_parse_dev_scope()
      for later reuse.
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      bb3a6b78
    • Jiang Liu's avatar
      iommu/vt-d: Avoid caching stale domain_device_info when hot-removing PCI device · 7e7dfab7
      Jiang Liu authored
      Function device_notifier() in intel-iommu.c only remove domain_device_info
      data structure associated with a PCI device when handling PCI device
      driver unbinding events. If a PCI device has never been bound to a PCI
      device driver, there won't be BUS_NOTIFY_UNBOUND_DRIVER event when
      hot-removing the PCI device. So associated domain_device_info data
      structure may get lost.
      
      On the other hand, if iommu_pass_through is enabled, function
      iommu_prepare_static_indentify_mapping() will create domain_device_info
      data structure for each PCIe to PCIe bridge and PCIe endpoint,
      no matter whether there are drivers associated with those PCIe devices
      or not. So those domain_device_info data structures will get lost when
      hot-removing the assocated PCIe devices if they have never bound to
      any PCI device driver.
      
      To be even worse, it's not only an memory leak issue, but also an
      caching of stale information bug because the memory are kept in
      device_domain_list and domain->devices lists.
      
      Fix the bug by trying to remove domain_device_info data structure when
      handling BUS_NOTIFY_DEL_DEVICE event.
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      7e7dfab7
    • Jiang Liu's avatar
      iommu/vt-d: Avoid caching stale domain_device_info and fix memory leak · 816997d0
      Jiang Liu authored
      Function device_notifier() in intel-iommu.c fails to remove
      device_domain_info data structures for PCI devices if they are
      associated with si_domain because iommu_no_mapping() returns true
      for those PCI devices. This will cause memory leak and caching of
      stale information in domain->devices list.
      
      So fix the issue by not calling iommu_no_mapping() and skipping check
      of iommu_pass_through.
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      816997d0
    • Jiang Liu's avatar
      iommu/vt-d: Avoid double free of g_iommus on error recovery path · 989d51fc
      Jiang Liu authored
      Array 'g_iommus' may be freed twice on error recovery path in function
      init_dmars() and free_dmar_iommu(), thus cause random system crash as
      below.
      
      [    6.774301] IOMMU: dmar init failed
      [    6.778310] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
      [    6.785615] software IO TLB [mem 0x76bcf000-0x7abcf000] (64MB) mapped at [ffff880076bcf000-ffff88007abcefff]
      [    6.796887] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
      [    6.804173] Modules linked in:
      [    6.807731] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc1+ #108
      [    6.815122] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0047.R00.1402050741 02/05/2014
      [    6.836000] task: ffff880455a80000 ti: ffff880455a88000 task.ti: ffff880455a88000
      [    6.844487] RIP: 0010:[<ffffffff8143eea6>]  [<ffffffff8143eea6>] memcpy+0x6/0x110
      [    6.853039] RSP: 0000:ffff880455a89cc8  EFLAGS: 00010293
      [    6.859064] RAX: ffff006568636163 RBX: ffff00656863616a RCX: 0000000000000005
      [    6.867134] RDX: 0000000000000005 RSI: ffffffff81cdc439 RDI: ffff006568636163
      [    6.875205] RBP: ffff880455a89d30 R08: 000000000001bc3b R09: 0000000000000000
      [    6.883275] R10: 0000000000000000 R11: ffffffff81cdc43e R12: ffff880455a89da8
      [    6.891338] R13: ffff006568636163 R14: 0000000000000005 R15: ffffffff81cdc439
      [    6.899408] FS:  0000000000000000(0000) GS:ffff88045b800000(0000) knlGS:0000000000000000
      [    6.908575] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    6.915088] CR2: ffff88047e1ff000 CR3: 0000000001e0e000 CR4: 00000000001407f0
      [    6.923160] Stack:
      [    6.925487]  ffffffff8143c904 ffff88045b407e00 ffff006568636163 ffff006568636163
      [    6.934113]  ffffffff8120a1a9 ffffffff81cdc43e 0000000000000007 0000000000000000
      [    6.942747]  ffff880455a89da8 ffff006568636163 0000000000000007 ffffffff81cdc439
      [    6.951382] Call Trace:
      [    6.954197]  [<ffffffff8143c904>] ? vsnprintf+0x124/0x6f0
      [    6.960323]  [<ffffffff8120a1a9>] ? __kmalloc_track_caller+0x169/0x360
      [    6.967716]  [<ffffffff81440e1b>] kvasprintf+0x6b/0x80
      [    6.973552]  [<ffffffff81432bf1>] kobject_set_name_vargs+0x21/0x70
      [    6.980552]  [<ffffffff8143393d>] kobject_init_and_add+0x4d/0x90
      [    6.987364]  [<ffffffff812067c9>] ? __kmalloc+0x169/0x370
      [    6.993492]  [<ffffffff8102dbbc>] ? cache_add_dev+0x17c/0x4f0
      [    7.000005]  [<ffffffff8102ddfa>] cache_add_dev+0x3ba/0x4f0
      [    7.006327]  [<ffffffff821a87ca>] ? i8237A_init_ops+0x14/0x14
      [    7.012842]  [<ffffffff821a87f8>] cache_sysfs_init+0x2e/0x61
      [    7.019260]  [<ffffffff81002162>] do_one_initcall+0xf2/0x220
      [    7.025679]  [<ffffffff810a4a29>] ? parse_args+0x2c9/0x450
      [    7.031903]  [<ffffffff8219d1b1>] kernel_init_freeable+0x1c9/0x25b
      [    7.038904]  [<ffffffff8219c8d2>] ? do_early_param+0x8a/0x8a
      [    7.045322]  [<ffffffff8184d5e0>] ? rest_init+0x150/0x150
      [    7.051447]  [<ffffffff8184d5ee>] kernel_init+0xe/0x100
      [    7.057380]  [<ffffffff8187b87c>] ret_from_fork+0x7c/0xb0
      [    7.063503]  [<ffffffff8184d5e0>] ? rest_init+0x150/0x150
      [    7.069628] Code: 89 e5 53 48 89 fb 75 16 80 7f 3c 00 75 05 e8 d2 f9 ff ff 48 8b 43 58 48 2b 43 50 88 43 4e 5b 5d c3 90 90 90 90 48 89 f8 48 89 d1 <f3> a4 c3 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 20 4c 8b 06 4c 8b
      [    7.094960] RIP  [<ffffffff8143eea6>] memcpy+0x6/0x110
      [    7.100856]  RSP <ffff880455a89cc8>
      [    7.104864] ---[ end trace b5d3fdc6c6c28083 ]---
      [    7.110142] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      [    7.110142]
      [    7.120540] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      989d51fc
  2. 03 Mar, 2014 1 commit
  3. 02 Mar, 2014 15 commits
  4. 01 Mar, 2014 2 commits
  5. 28 Feb, 2014 13 commits