1. 05 Feb, 2014 10 commits
  2. 03 Feb, 2014 9 commits
    • Rafael J. Wysocki's avatar
      ACPI / hotplug / PCI: Fix bridge removal race vs dock events · af9d8adc
      Rafael J. Wysocki authored
      If a PCI bridge with an ACPIPHP context attached is removed via
      sysfs, the code path executed as a result is the following:
      
      pci_stop_and_remove_bus_device_locked
       pci_remove_bus
        pcibios_remove_bus
         acpi_pci_remove_bus
          acpiphp_remove_slots
           cleanup_bridge
            unregister_hotplug_dock_device (drops dock references to the bridge)
           put_bridge
            free_bridge
             acpiphp_put_context (for each child, under context lock)
              kfree (context)
      
      Now, if a dock event affecting one of the bridge's child devices
      occurs (roughly at the same time), it will lead to the following code
      path:
      
      acpi_dock_deferred_cb
       dock_notify
        handle_eject_request
         hot_remove_dock_devices
          dock_hotplug_event
           hotplug_event (dereferences context)
      
      That may lead to a kernel crash in hotplug_event() if it is executed
      after the last kfree() in the bridge removal code path.
      
      To prevent that from happening, add a wrapper around hotplug_event()
      called dock_event() and point the .handler pointer in acpiphp_dock_ops
      to it.  Make that wrapper retrieve the device's ACPIPHP context using
      acpiphp_get_context() (instead of taking it from the data argument)
      under acpiphp_context_lock and check if the parent bridge's
      is_going_away flag is set.  If that flag is set, it will return
      immediately and if it is not set it will grab a reference to the
      device's parent bridge before executing hotplug_event().
      
      Then, in the above scenario, the reference to the parent bridge
      held by dock_event() will prevent free_bridge() from being executed
      for it until hotplug_event() returns.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      af9d8adc
    • Rafael J. Wysocki's avatar
      ACPI / hotplug / PCI: Fix bridge removal race in handle_hotplug_event() · 1b360f44
      Rafael J. Wysocki authored
      If a PCI bridge with an ACPIPHP context attached is removed via
      sysfs, the code path executed as a result is the following:
      
      pci_stop_and_remove_bus_device_locked
       pci_remove_bus
        pcibios_remove_bus
         acpi_pci_remove_bus
          acpiphp_remove_slots
           cleanup_bridge
           put_bridge
            free_bridge
             acpiphp_put_context (for each child, under context lock)
              kfree (child context)
      
      Now, if a hotplug notify is dispatched for one of the bridge's
      children and the timing is such that handle_hotplug_event() for
      that notify is executed while free_bridge() above is running,
      the get_bridge(context->func.parent) in handle_hotplug_event()
      will not really help, because it is too late to prevent the bridge
      from going away and the child's context may be freed before
      hotplug_event_work() scheduled from handle_hotplug_event()
      dereferences the pointer to it passed via the data argument.
      That will cause a kernel crash to happpen in hotplug_event_work().
      
      To prevent that from happening, make handle_hotplug_event()
      check the is_going_away flag of the function's parent bridge
      (under acpiphp_context_lock) and bail out if it's set.  Also,
      make cleanup_bridge() set the bridge's is_going_away flag under
      acpiphp_context_lock so that it cannot be changed between the
      check and the subsequent get_bridge(context->func.parent) in
      handle_hotplug_event().
      
      Then, in the above scenario, handle_hotplug_event() will notice
      that context->func.parent->is_going_away is already set and it
      will exit immediately preventing the crash from happening.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1b360f44
    • Rafael J. Wysocki's avatar
      ACPI / hotplug / PCI: Scan root bus under the PCI rescan-remove lock · d42f5da2
      Rafael J. Wysocki authored
      Since acpiphp_check_bridge() called by acpiphp_check_host_bridge()
      does things that require PCI rescan-remove locking around it,
      make acpiphp_check_host_bridge() use that locking.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      d42f5da2
    • Rafael J. Wysocki's avatar
      ACPI / hotplug / PCI: Move PCI rescan-remove locking to hotplug_event() · f41b3261
      Rafael J. Wysocki authored
      Commit 9217a984 (ACPI / hotplug / PCI: Use global PCI rescan-remove
      locking) modified ACPIPHP to protect its PCI device removal and addition
      code paths from races against sysfs-driven rescan and remove operations
      with the help of PCI rescan-remove locking.  However, it overlooked the
      fact that hotplug_event_work() is not the only caller of hotplug_event()
      which may also be called by dock_hotplug_event() and that code path
      is missing the PCI rescan-remove locking.  This means that, although
      the PCI rescan-remove lock is held as appropriate during the handling
      of events originating from handle_hotplug_event(), the ACPIPHP's
      operations resulting from dock events may still suffer the race
      conditions that commit 9217a984 was supposed to eliminate.
      
      To address that problem, move the PCI rescan-remove locking from
      hotplug_event_work() to hotplug_event() so that it is used regardless
      of the way that function is invoked.
      
      Revamps: 9217a984 (ACPI / hotplug / PCI: Use global PCI rescan-remove locking)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      f41b3261
    • Rafael J. Wysocki's avatar
      ACPI / hotplug / PCI: Remove entries from bus->devices in reverse order · 2d7c1b77
      Rafael J. Wysocki authored
      According to the changelog of commit 29ed1f29 (PCI: pciehp: Fix null
      pointer deref when hot-removing SR-IOV device) it is unsafe to walk the
      bus->devices list of a PCI bus and remove devices from it in direct order,
      because that may lead to NULL pointer dereferences related to virtual
      functions.
      
      For this reason, change all of the bus->devices list walks in
      acpiphp_glue.c during which devices may be removed to be carried out in
      reverse order.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      2d7c1b77
    • Linus Torvalds's avatar
      Linus 3.14-rc1 · 38dbfb59
      Linus Torvalds authored
      38dbfb59
    • Linus Torvalds's avatar
      Merge branch 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 69048e01
      Linus Torvalds authored
      Pull parisc updates from Helge Deller:
       "The three major changes in this patchset is a implementation for
        flexible userspace memory maps, cache-flushing fixes (again), and a
        long-discussed ABI change to make EWOULDBLOCK the same value as
        EAGAIN.
      
        parisc has been the only platform where we had EWOULDBLOCK != EAGAIN
        to keep HP-UX compatibility.  Since we will probably never implement
        full HP-UX support, we prefer to drop this compatibility to make it
        easier for us with Linux userspace programs which mostly never checked
        for both values.  We don't expect major fall-outs because of this
        change, and if we face some, we will simply rebuild the necessary
        applications in the debian archives"
      
      * 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: add flexible mmap memory layout support
        parisc: Make EWOULDBLOCK be equal to EAGAIN on parisc
        parisc: convert uapi/asm/stat.h to use native types only
        parisc: wire up sched_setattr and sched_getattr
        parisc: fix cache-flushing
        parisc/sti_console: prefer Linux fonts over built-in ROM fonts
      69048e01
    • Mikulas Patocka's avatar
      hpfs: optimize quad buffer loading · 1c0b8a7a
      Mikulas Patocka authored
      HPFS needs to load 4 consecutive 512-byte sectors when accessing the
      directory nodes or bitmaps.  We can't switch to 2048-byte block size
      because files are allocated in the units of 512-byte sectors.
      
      Previously, the driver would allocate a 2048-byte area using kmalloc,
      copy the data from four buffers to this area and eventually copy them
      back if they were modified.
      
      In the current implementation of the buffer cache, buffers are allocated
      in the pagecache.  That means that 4 consecutive 512-byte buffers are
      stored in consecutive areas in the kernel address space.  So, we don't
      need to allocate extra memory and copy the content of the buffers there.
      
      This patch optimizes the code to avoid copying the buffers.  It checks
      if the four buffers are stored in contiguous memory - if they are not,
      it falls back to allocating a 2048-byte area and copying data there.
      Signed-off-by: default avatarMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1c0b8a7a
    • Mikulas Patocka's avatar
      hpfs: remember free space · 2cbe5c76
      Mikulas Patocka authored
      Previously, hpfs scanned all bitmaps each time the user asked for free
      space using statfs.  This patch changes it so that hpfs scans the
      bitmaps only once, remembes the free space and on next invocation of
      statfs it returns the value instantly.
      
      New versions of wine are hammering on the statfs syscall very heavily,
      making some games unplayable when they're stored on hpfs, with load
      times in minutes.
      
      This should be backported to the stable kernels because it fixes
      user-visible problem (excessive level load times in wine).
      Signed-off-by: default avatarMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2cbe5c76
  3. 02 Feb, 2014 12 commits
  4. 01 Feb, 2014 9 commits