Skip to content
Snippets Groups Projects
  1. Feb 26, 2010
  2. Feb 25, 2010
  3. Feb 24, 2010
  4. Feb 23, 2010
  5. Feb 21, 2010
  6. Feb 20, 2010
  7. Feb 19, 2010
    • Brandon Philips's avatar
      x86, irq: Keep chip_data in create_irq_nr and destroy_irq · eb5b3794
      Brandon Philips authored
      
      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: default avatarBrandon Philips <bphilips@suse.de>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <20100207210250.GB8256@jenkins.home.ifup.org>
      Signed-off-by: default avatarBrandon Phiilps <bphilips@suse.de>
      Cc: stable@kernel.org
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      eb5b3794
    • Eric W. Biederman's avatar
      xen: Remove unnecessary arch specific xen irq functions. · ca4dbc66
      Eric W. Biederman authored
      
      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: default avatarEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <4B7CAAD2.10803@kernel.org>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Ian Campbell <Ian.Campbell@citrix.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      ca4dbc66
  8. Feb 18, 2010
  9. Feb 17, 2010