1. 25 2月, 2010 1 次提交
    • J
      x86, apbt: Moorestown APB system timer driver · bb24c471
      Jacob Pan 提交于
      Moorestown platform does not have PIT or HPET platform timers.  Instead it
      has a bank of eight APB timers.  The number of available timers to the os
      is exposed via SFI mtmr tables.  All APB timer interrupts are routed via
      ioapic rtes and delivered as MSI.
      Currently, we use timer 0 and 1 for per cpu clockevent devices, timer 2
      for clocksource.
      Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com>
      LKML-Reference: <43F901BD926A4E43B106BF17856F0755A318D2D2@orsmsx508.amr.corp.intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      bb24c471
  2. 24 2月, 2010 8 次提交
  3. 23 2月, 2010 2 次提交
  4. 21 2月, 2010 1 次提交
  5. 20 2月, 2010 9 次提交
  6. 19 2月, 2010 2 次提交
    • B
      x86, irq: Keep chip_data in create_irq_nr and destroy_irq · eb5b3794
      Brandon Philips 提交于
      Version 4: use get_irq_chip_data() in destroy_irq() to get rid of some
      local vars.
      
      When two drivers are setting up MSI-X at the same time via
      pci_enable_msix() there is a race.  See this dmesg excerpt:
      
      [   85.170610] ixgbe 0000:02:00.1: irq 97 for MSI/MSI-X
      [   85.170611]   alloc irq_desc for 99 on node -1
      [   85.170613] igb 0000:08:00.1: irq 98 for MSI/MSI-X
      [   85.170614]   alloc kstat_irqs on node -1
      [   85.170616] alloc irq_2_iommu on node -1
      [   85.170617]   alloc irq_desc for 100 on node -1
      [   85.170619]   alloc kstat_irqs on node -1
      [   85.170621] alloc irq_2_iommu on node -1
      [   85.170625] ixgbe 0000:02:00.1: irq 99 for MSI/MSI-X
      [   85.170626]   alloc irq_desc for 101 on node -1
      [   85.170628] igb 0000:08:00.1: irq 100 for MSI/MSI-X
      [   85.170630]   alloc kstat_irqs on node -1
      [   85.170631] alloc irq_2_iommu on node -1
      [   85.170635]   alloc irq_desc for 102 on node -1
      [   85.170636]   alloc kstat_irqs on node -1
      [   85.170639] alloc irq_2_iommu on node -1
      [   85.170646] BUG: unable to handle kernel NULL pointer dereference
      at 0000000000000088
      
      As you can see igb and ixgbe are both alternating on create_irq_nr()
      via pci_enable_msix() in their probe function.
      
      ixgbe: While looping through irq_desc_ptrs[] via create_irq_nr() ixgbe
      choses irq_desc_ptrs[102] and exits the loop, drops vector_lock and
      calls dynamic_irq_init. Then it sets irq_desc_ptrs[102]->chip_data =
      NULL via dynamic_irq_init().
      
      igb: Grabs the vector_lock now and starts looping over irq_desc_ptrs[]
      via create_irq_nr(). It gets to irq_desc_ptrs[102] and does this:
      
      	cfg_new = irq_desc_ptrs[102]->chip_data;
      	if (cfg_new->vector != 0)
      		continue;
      
      This hits the NULL deref.
      
      Another possible race exists via pci_disable_msix() in a driver or in
      the number of error paths that call free_msi_irqs():
      
      destroy_irq()
      dynamic_irq_cleanup() which sets desc->chip_data = NULL
      ...race window...
      desc->chip_data = cfg;
      
      Remove the save and restore code for cfg in create_irq_nr() and
      destroy_irq() and take the desc->lock when checking the irq_cfg.
      Reported-and-analyzed-by: NBrandon Philips <bphilips@suse.de>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <20100207210250.GB8256@jenkins.home.ifup.org>
      Signed-off-by: NBrandon Phiilps <bphilips@suse.de>
      Cc: stable@kernel.org
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      eb5b3794
    • E
      xen: Remove unnecessary arch specific xen irq functions. · ca4dbc66
      Eric W. Biederman 提交于
      Right now xen's use of the x86 and ia64 handle_irq is just bizarre and very
      fragile as it is very non-obvious the function exists and is is used by
      code out in drivers/....  Luckily using handle_irq is completely unnecessary,
      and we can just use the generic irq apis instead.
      
      This still leaves drivers/xen/events.c as a problematic user of the generic
      irq apis it has "static struct irq_info irq_info[NR_IRQS]" but that can be
      fixed some other time.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <4B7CAAD2.10803@kernel.org>
      Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Ian Campbell <Ian.Campbell@citrix.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      ca4dbc66
  7. 18 2月, 2010 6 次提交
  8. 17 2月, 2010 4 次提交
  9. 13 2月, 2010 7 次提交