1. 15 9月, 2016 1 次提交
    • B
      PCI/AER: Remove aerdriver.forceload kernel parameter · 7ece1417
      Bjorn Helgaas 提交于
      Per the PCI Firmware spec, r3.0, sec 4.5.1, on ACPI systems, the OS must
      not use AER unless _OSC is present and _OSC grants AER control to the OS.
      The aerdriver.forceload kernel parameter was a way to enable Linux AER
      support on ACPI systems that lack _OSC or fail to grant control the the OS.
      
      Enabling Linux AER support when the firmware doesn't want us to is a recipe
      for problems, e.g., the firmware might be handling AER itself.
      
      Remove the aerdriver.forceload kernel parameter and related supporting
      code.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      7ece1417
  2. 26 1月, 2016 1 次提交
    • S
      PCI/AER: Flush workqueue on device remove to avoid use-after-free · 4ae2182b
      Sebastian Andrzej Siewior 提交于
      A Root Port's AER structure (rpc) contains a queue of events.  aer_irq()
      enqueues AER status information and schedules aer_isr() to dequeue and
      process it.  When we remove a device, aer_remove() waits for the queue to
      be empty, then frees the rpc struct.
      
      But aer_isr() references the rpc struct after dequeueing and possibly
      emptying the queue, which can cause a use-after-free error as in the
      following scenario with two threads, aer_isr() on the left and a
      concurrent aer_remove() on the right:
      
        Thread A                      Thread B
        --------                      --------
        aer_irq():
          rpc->prod_idx++
                                      aer_remove():
                                        wait_event(rpc->prod_idx == rpc->cons_idx)
                                        # now blocked until queue becomes empty
        aer_isr():                      # ...
          rpc->cons_idx++               # unblocked because queue is now empty
          ...                           kfree(rpc)
          mutex_unlock(&rpc->rpc_mutex)
      
      To prevent this problem, use flush_work() to wait until the last scheduled
      instance of aer_isr() has completed before freeing the rpc struct in
      aer_remove().
      
      I reproduced this use-after-free by flashing a device FPGA and
      re-enumerating the bus to find the new device.  With SLUB debug, this
      crashes with 0x6b bytes (POISON_FREE, the use-after-free magic number) in
      GPR25:
      
        pcieport 0000:00:00.0: AER: Multiple Corrected error received: id=0000
        Unable to handle kernel paging request for data at address 0x27ef9e3e
        Workqueue: events aer_isr
        GPR24: dd6aa000 6b6b6b6b 605f8378 605f8360 d99b12c0 604fc674 606b1704 d99b12c0
        NIP [602f5328] pci_walk_bus+0xd4/0x104
      
      [bhelgaas: changelog, stable tag]
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      4ae2182b
  3. 15 8月, 2013 1 次提交
  4. 29 11月, 2012 1 次提交
  5. 08 9月, 2012 1 次提交
  6. 24 8月, 2012 1 次提交
  7. 23 8月, 2012 1 次提交
  8. 15 1月, 2011 1 次提交
  9. 16 10月, 2010 1 次提交
    • R
      PCI/PCIe/AER: Disable native AER service if BIOS has precedence · b22c3d82
      Rafael J. Wysocki 提交于
      There is a design issue related to PCIe AER and _OSC that the BIOS
      may be asked to grant control of the AER service even if some
      Hardware Error Source Table (HEST) entries contain information
      meaning that the BIOS really should control it.  Namely,
      pcie_port_acpi_setup() calls pcie_aer_get_firmware_first() that
      determines whether or not the AER service should be controlled by
      the BIOS on the basis of the HEST information for the given PCIe
      port.  The BIOS is asked to grant control of the AER service for
      a PCIe Root Complex if pcie_aer_get_firmware_first() returns 'false'
      for at least one root port in that complex, even if all of the other
      root ports' HEST entries have the FIRMWARE_FIRST flag set (and none
      of them has the GLOBAL flag set).  However, if the AER service is
      controlled by the kernel, that may interfere with the BIOS' handling
      of the error sources having the FIRMWARE_FIRST flag.  Moreover,
      there may be PCIe endpoints that have the FIRMWARE_FIRST flag set in
      HEST and are attached to the root ports in question, in which case it
      also may be unsafe to ask the BIOS for control of the AER service.
      
      For this reason, introduce a function checking if there's at least
      one PCIe-related HEST entry with the FIRMWARE_FIRST flag set and
      disable the native AER service altogether if this function returns
      'true'.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b22c3d82
  10. 25 8月, 2010 1 次提交
  11. 12 5月, 2010 7 次提交
  12. 09 4月, 2010 1 次提交
  13. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  14. 17 12月, 2009 1 次提交
  15. 05 12月, 2009 1 次提交
  16. 25 11月, 2009 1 次提交
  17. 12 10月, 2009 1 次提交
  18. 08 10月, 2009 1 次提交
  19. 18 9月, 2009 1 次提交
  20. 10 9月, 2009 1 次提交
    • H
      PCI: pcie, aer: checkpatch style cleanup in pcie/aer/* · c9a91883
      Hidetoshi Seto 提交于
      Before:
       drivers/pci/pcie/aer/aer_inject.c
        total: 4 errors, 4 warnings, 473 lines checked
       drivers/pci/pcie/aer/aerdrv.c
        total: 5 errors, 2 warnings, 333 lines checked
       drivers/pci/pcie/aer/aerdrv.h
        total: 1 errors, 0 warnings, 139 lines checked
       drivers/pci/pcie/aer/aerdrv_core.c
        total: 4 errors, 3 warnings, 872 lines checked
       drivers/pci/pcie/aer/aerdrv_errprint.c
        total: 12 errors, 11 warnings, 248 lines checked
      
      After:
       drivers/pci/pcie/aer/aer_inject.c
        total: 0 errors, 0 warnings, 466 lines checked
       drivers/pci/pcie/aer/aerdrv.c
        total: 0 errors, 0 warnings, 335 lines checked
       drivers/pci/pcie/aer/aerdrv.h
        total: 0 errors, 0 warnings, 139 lines checked
       drivers/pci/pcie/aer/aerdrv_core.c
        total: 0 errors, 0 warnings, 869 lines checked
       drivers/pci/pcie/aer/aerdrv_errprint.c
        total: 0 errors, 10 warnings, 247 lines checked
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Reviewed-by: NAndrew Patterson <andrew.patterson@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      c9a91883
  21. 17 6月, 2009 1 次提交
  22. 21 3月, 2009 1 次提交
  23. 20 3月, 2009 2 次提交
  24. 21 10月, 2008 1 次提交
  25. 26 6月, 2008 1 次提交
  26. 11 6月, 2008 1 次提交
  27. 21 4月, 2008 1 次提交
  28. 13 10月, 2007 1 次提交
  29. 20 7月, 2007 1 次提交
  30. 12 7月, 2007 1 次提交
  31. 10 3月, 2007 1 次提交
  32. 15 2月, 2007 1 次提交
  33. 14 12月, 2006 1 次提交
    • R
      [PATCH] getting rid of all casts of k[cmz]alloc() calls · 5cbded58
      Robert P. J. Day 提交于
      Run this:
      
      	#!/bin/sh
      	for f in $(grep -Erl "\([^\)]*\) *k[cmz]alloc" *) ; do
      	  echo "De-casting $f..."
      	  perl -pi -e "s/ ?= ?\([^\)]*\) *(k[cmz]alloc) *\(/ = \1\(/" $f
      	done
      
      And then go through and reinstate those cases where code is casting pointers
      to non-pointers.
      
      And then drop a few hunks which conflicted with outstanding work.
      
      Cc: Russell King <rmk@arm.linux.org.uk>, Ian Molton <spyro@f2s.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Paul Fulghum <paulkf@microgate.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Karsten Keil <kkeil@suse.de>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Cc: Jaroslav Kysela <perex@suse.cz>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cbded58