1. 20 Jan, 2014 1 commit
  2. 19 Jan, 2014 1 commit
  3. 16 Jan, 2014 2 commits
    • Tejun Heo's avatar
      libata: disable LPM for some WD SATA-I devices · ecd75ad5
      Tejun Heo authored
      For some reason, some early WD drives spin up and down drives
      erratically when the link is put into slumber mode which can reduce
      the life expectancy of the device significantly.  Unfortunately, we
      don't have full list of devices and given the nature of the issue it'd
      be better to err on the side of false positives than the other way
      around.  Let's disable LPM on all WD devices which match one of the
      known problematic model prefixes and are SATA-I.
      
      As horkage list doesn't support matching SATA capabilities, this is
      implemented as two horkages - WD_BROKEN_LPM and NOLPM.  The former is
      set for the known prefixes and sets the latter if the matched device
      is SATA-I.
      
      Note that this isn't optimal as this disables all LPM operations and
      partial link power state reportedly works fine on these; however, the
      way LPM is implemented in libata makes it difficult to precisely map
      libata LPM setting to specific link power state.  Well, these devices
      are already fairly outdated.  Let's just disable whole LPM for now.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-and-tested-by: default avatarNikos Barkas <levelwol@gmail.com>
      Reported-and-tested-by: default avatarIoannis Barkas <risc4all@yahoo.com>
      References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
      Cc: stable@vger.kernel.org
      ecd75ad5
    • Tejun Heo's avatar
      Merge branch 'for-3.13-fixes' into for-3.14 · 6e1af697
      Tejun Heo authored
      A scheduled horkage patch will conflict with HORKAGE changes in
      for-3.13-fixes.  Pull in to avoid unnecessary merge conflicts.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      6e1af697
  4. 15 Jan, 2014 3 commits
  5. 12 Jan, 2014 1 commit
  6. 02 Jan, 2014 2 commits
  7. 01 Jan, 2014 1 commit
  8. 31 Dec, 2013 2 commits
  9. 19 Dec, 2013 1 commit
    • Tejun Heo's avatar
      libata, freezer: avoid block device removal while system is frozen · 85fbd722
      Tejun Heo authored
      Freezable kthreads and workqueues are fundamentally problematic in
      that they effectively introduce a big kernel lock widely used in the
      kernel and have already been the culprit of several deadlock
      scenarios.  This is the latest occurrence.
      
      During resume, libata rescans all the ports and revalidates all
      pre-existing devices.  If it determines that a device has gone
      missing, the device is removed from the system which involves
      invalidating block device and flushing bdi while holding driver core
      layer locks.  Unfortunately, this can race with the rest of device
      resume.  Because freezable kthreads and workqueues are thawed after
      device resume is complete and block device removal depends on
      freezable workqueues and kthreads (e.g. bdi_wq, jbd2) to make
      progress, this can lead to deadlock - block device removal can't
      proceed because kthreads are frozen and kthreads can't be thawed
      because device resume is blocked behind block device removal.
      
      839a8e86 ("writeback: replace custom worker pool implementation
      with unbound workqueue") made this particular deadlock scenario more
      visible but the underlying problem has always been there - the
      original forker task and jbd2 are freezable too.  In fact, this is
      highly likely just one of many possible deadlock scenarios given that
      freezer behaves as a big kernel lock and we don't have any debug
      mechanism around it.
      
      I believe the right thing to do is getting rid of freezable kthreads
      and workqueues.  This is something fundamentally broken.  For now,
      implement a funny workaround in libata - just avoid doing block device
      hot[un]plug while the system is frozen.  Kernel engineering at its
      finest.  :(
      
      v2: Add EXPORT_SYMBOL_GPL(pm_freezing) for cases where libata is built
          as a module.
      
      v3: Comment updated and polling interval changed to 10ms as suggested
          by Rafael.
      
      v4: Add #ifdef CONFIG_FREEZER around the hack as pm_freezing is not
          defined when FREEZER is not configured thus breaking build.
          Reported by kbuild test robot.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarTomaž Šolc <tomaz.solc@tablix.org>
      Reviewed-by: default avatar"Rafael J. Wysocki" <rjw@rjwysocki.net>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=62801
      Link: http://lkml.kernel.org/r/20131213174932.GA27070@htj.dyndns.org
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: stable@vger.kernel.org
      Cc: kbuild test robot <fengguang.wu@intel.com>
      85fbd722
  10. 17 Dec, 2013 1 commit
  11. 16 Dec, 2013 2 commits
  12. 14 Dec, 2013 2 commits
  13. 12 Dec, 2013 1 commit
  14. 03 Dec, 2013 5 commits
  15. 02 Dec, 2013 1 commit
  16. 29 Nov, 2013 2 commits
  17. 27 Nov, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ATA: Fix port removal ordering · c5700766
      Rafael J. Wysocki authored
      After commit bcdde7e2 (sysfs: make __sysfs_remove_dir() recursive)
      Mika Westerberg sees traces analogous to the one below in Thunderbolt
      hot-remove testing:
      
       WARNING: CPU: 0 PID: 4 at fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()
       sysfs group ffffffff81c6f1e0 not found for kobject 'host7'
       Modules linked in:
       CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.12.0+ #13
       Hardware name:                  /D33217CK, BIOS GKPPT10H.86A.0042.2013.0422.1439 04/22/2013
       Workqueue: kacpi_hotplug acpi_hotplug_work_fn
        0000000000000009 ffff8801002459b0 ffffffff817daab1 ffff8801002459f8
        ffff8801002459e8 ffffffff810436b8 0000000000000000 ffffffff81c6f1e0
        ffff88006d440358 ffff88006d440188 ffff88006e8b4c28 ffff880100245a48
       Call Trace:
        [<ffffffff817daab1>] dump_stack+0x45/0x56
        [<ffffffff810436b8>] warn_slowpath_common+0x78/0xa0
        [<ffffffff81043727>] warn_slowpath_fmt+0x47/0x50
        [<ffffffff811ad319>] ? sysfs_get_dirent_ns+0x49/0x70
        [<ffffffff811ae526>] sysfs_remove_group+0xc6/0xd0
        [<ffffffff81432f7e>] dpm_sysfs_remove+0x3e/0x50
        [<ffffffff8142a0d0>] device_del+0x40/0x1b0
        [<ffffffff8142a24d>] device_unregister+0xd/0x20
        [<ffffffff8144131a>] scsi_remove_host+0xba/0x110
        [<ffffffff8145f526>] ata_host_detach+0xc6/0x100
        [<ffffffff8145f578>] ata_pci_remove_one+0x18/0x20
        [<ffffffff812e8f48>] pci_device_remove+0x28/0x60
        [<ffffffff8142d854>] __device_release_driver+0x64/0xd0
        [<ffffffff8142d8de>] device_release_driver+0x1e/0x30
        [<ffffffff8142d257>] bus_remove_device+0xf7/0x140
        [<ffffffff8142a1b1>] device_del+0x121/0x1b0
        [<ffffffff812e43d4>] pci_stop_bus_device+0x94/0xa0
        [<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
        [<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
        [<ffffffff812e44dd>] pci_stop_and_remove_bus_device+0xd/0x20
        [<ffffffff812fc743>] trim_stale_devices+0x73/0xe0
        [<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
        [<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
        [<ffffffff812fcb6e>] acpiphp_check_bridge+0x7e/0xd0
        [<ffffffff812fd90d>] hotplug_event+0xcd/0x160
        [<ffffffff812fd9c5>] hotplug_event_work+0x25/0x60
        [<ffffffff81316749>] acpi_hotplug_work_fn+0x17/0x22
        [<ffffffff8105cf3a>] process_one_work+0x17a/0x430
        [<ffffffff8105db29>] worker_thread+0x119/0x390
        [<ffffffff8105da10>] ? manage_workers.isra.25+0x2a0/0x2a0
        [<ffffffff81063a5d>] kthread+0xcd/0xf0
        [<ffffffff81063990>] ? kthread_create_on_node+0x180/0x180
        [<ffffffff817eb33c>] ret_from_fork+0x7c/0xb0
        [<ffffffff81063990>] ? kthread_create_on_node+0x180/0x180
      
      The source of this problem is that SCSI hosts are removed from
      ATA ports after calling ata_tport_delete() which removes the
      port's sysfs directory, among other things.  Now, after commit
      bcdde7e2, the sysfs directory is removed along with all of
      its subdirectories that include the SCSI host's sysfs directory
      and its subdirectories at this point.  Consequently, when
      device_del() is finally called for any child device of the SCSI
      host and tries to remove its "power" group (which is already
      gone then), it triggers the above warning.
      
      To make the warnings go away, change the removal ordering in
      ata_port_detach() so that the SCSI host is removed from the
      port before ata_tport_delete() is called.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=65281Reported-and-tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      c5700766
  18. 23 Nov, 2013 3 commits
  19. 22 Nov, 2013 8 commits