Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 9月, 2012 2 次提交
  3. 26 9月, 2012 5 次提交
  5. 22 9月, 2012 1 次提交
  7. 06 9月, 2012 1 次提交
  9. 21 8月, 2012 1 次提交
  11. 16 8月, 2012 1 次提交
  13. 20 7月, 2012 2 次提交
  15. 17 7月, 2012 2 次提交
  17. 26 6月, 2012 7 次提交
  19. 23 6月, 2012 2 次提交
    • A
      usb-storage: revert commit afff07e6 (Add 090c:1000 to unusal-devs) · 0070513b
      由 Alan Stern 提交于 
      This patch (as1560) reverts commit
afff07e6 (usb-storage: Add 090c:1000
to unusal-devs).  It is no longer needed, because usb-storage now
tells the sd driver to try READ CAPACITY(10) before READ CAPACITY(16)
for every USB mass-storage device.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NHans de Goede <hdegoede@redhat.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0070513b
    • A
      SCSI & usb-storage: add try_rc_10_first flag · 6a0bdffa
      由 Alan Stern 提交于 
      Several bug reports have been received recently for USB mass-storage
devices that don't handle READ CAPACITY(16) commands properly.  They
report bogus sizes, in some cases becoming unusable as a result.

The bugs were triggered by commit
09b6b51b (SCSI & usb-storage: add
flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
overriding the SCSI level reported by devices.  By default, the sd
driver will try READ CAPACITY(16) first for any device whose level is
above SCSI_SPC_2.

It seems likely that any device large enough to require the use of
READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
CAPACITY(10) commands properly.  Indeed, I don't know of any devices
that don't handle READ CAPACITY(10) properly.

Therefore this patch (as1559) adds a new flag telling the sd driver
to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
for every USB mass-storage device.  If a device really is larger than
2 TB, sd will fall back to READ CAPACITY(16) just as it used to.

This fixes Bugzilla #43391.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NHans de Goede <hdegoede@redhat.com>
CC: "James E.J. Bottomley" <JBottomley@parallels.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a0bdffa
  21. 14 6月, 2012 2 次提交
  23. 18 5月, 2012 3 次提交
  25. 10 5月, 2012 1 次提交
  27. 19 4月, 2012 1 次提交
  29. 07 4月, 2012 1 次提交
    • M
      usb: storage: fix lockdep warning inside usb_stor_pre_reset(v2) · c825bab0
      由 Ming Lei 提交于 
      This patch fixes one lockdep warning[1] inside usb_stor_pre_reset.

If the current configuration includes multiple mass storage interfaces,
the 'AA' lockdep warning will be triggered since the lock class of
'us->dev_mutex' is acquired two times in .reset path. It isn't
a real deadlock, so just take the lockdep_set_class annotation to
remove the warning.

[1], lockdep warning log
:[ INFO: possible recursive locking detected ]
:3.3.0-0.rc5.git3.1.fc17.x86_64 #1 Tainted: G        W
:---------------------------------------------
:usb-storage/14846 is trying to acquire lock:
: (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
:but task is already holding lock:
: (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
:other info that might help us debug this:
: Possible unsafe locking scenario:
:       CPU0
:       ----
:  lock(&(us->dev_mutex));
:  lock(&(us->dev_mutex));
: *** DEADLOCK ***
: May be due to missing lock nesting notation
:2 locks held by usb-storage/14846:
: #0:  (&__lockdep_no_validate__){......}, at: [<ffffffff8147e6a5>] usb_lock_device_for_reset+0x95/0x100
: #1:  (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
:stack backtrace:
:Pid: 14846, comm: usb-storage Tainted: G        W 3.3.0-0.rc5.git3.1.fc17.x86_64 #1
:Call Trace:
: [<ffffffff810cbdaf>] __lock_acquire+0x168f/0x1bb0
: [<ffffffff81021083>] ? native_sched_clock+0x13/0x80
: [<ffffffff810210f9>] ? sched_clock+0x9/0x10
: [<ffffffff810210f9>] ? sched_clock+0x9/0x10
: [<ffffffff810a2975>] ? sched_clock_local+0x25/0xa0
: [<ffffffff810cc9a1>] lock_acquire+0xa1/0x1e0
: [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
: [<ffffffff81699c86>] mutex_lock_nested+0x76/0x3a0
: [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
: [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
: [<ffffffff8148184d>] usb_reset_device+0x7d/0x190
: [<ffffffffa048119c>] usb_stor_port_reset+0x7c/0x80 [usb_storage]
: [<ffffffffa0481234>] usb_stor_invoke_transport+0x94/0x560 [usb_storage]
: [<ffffffff810cd3b2>] ? mark_held_locks+0xb2/0x130
: [<ffffffff8169dbd0>] ? _raw_spin_unlock_irq+0x30/0x50
: [<ffffffffa047fe3e>] usb_stor_transparent_scsi_command+0xe/0x10 [usb_storage]
: [<ffffffffa0481ae3>] usb_stor_control_thread+0x173/0x280 [usb_storage]
: [<ffffffffa0481970>] ? fill_inquiry_response+0x20/0x20 [usb_storage]
: [<ffffffff8108a3f7>] kthread+0xb7/0xc0
: [<ffffffff816a7d34>] kernel_thread_helper+0x4/0x10
: [<ffffffff8169e0f4>] ? retint_restore_args+0x13/0x13
: [<ffffffff8108a340>] ? kthread_worker_fn+0x1a0/0x1a0
: [<ffffffff816a7d30>] ? gs_change+0x13/0x13
Reported-By: NDave Jones <davej@redhat.com>
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c825bab0
  31. 31 3月, 2012 1 次提交
  33. 28 3月, 2012 1 次提交
  35. 29 2月, 2012 2 次提交
  37. 25 2月, 2012 1 次提交
  39. 22 2月, 2012 1 次提交
    • A
      usb-storage: fix freezing of the scanning thread · bb94a406
      由 Alan Stern 提交于 
      This patch (as1521b) fixes the interaction between usb-storage's
scanning thread and the freezer.  The current implementation has a
race: If the device is unplugged shortly after being plugged in and
just as a system sleep begins, the scanning thread may get frozen
before the khubd task.  Khubd won't be able to freeze until the
disconnect processing is complete, and the disconnect processing can't
proceed until the scanning thread finishes, so the sleep transition
will fail.

The implementation in the 3.2 kernel suffers from an additional
problem.  There the scanning thread calls set_freezable_with_signal(),
and the signals sent by the freezer will mess up the thread's I/O
delays, which are all interruptible.

The solution to both problems is the same: Replace the kernel thread
used for scanning with a delayed-work routine on the system freezable
work queue.  Freezable work queues have the nice property that you can
cancel a work item even while the work queue is frozen, and no signals
are needed.

The 3.2 version of this patch solves the problem in Bugzilla #42730.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NSeth Forshee <seth.forshee@canonical.com>
CC: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb94a406
  41. 09 2月, 2012 2 次提交
    • A
      usb-storage: reorganize target-specific code · af74d2da
      由 Alan Stern 提交于 
      Now that usb-storage has a target_alloc() routine, this patch (as1508)
moves some existing target-specific code out of the slave_alloc()
routine to where it really belongs.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af74d2da
    • A
      SCSI & usb-storage: add flags for VPD pages and REPORT LUNS · 09b6b51b
      由 Alan Stern 提交于 
      This patch (as1507) adds a skip_vpd_pages flag to struct scsi_device
and a no_report_luns flag to struct scsi_target.  The first is used to
control whether sd will look at VPD pages for information on block
provisioning, limits, and characteristics.  The second prevents
scsi_report_lun_scan() from issuing a REPORT LUNS command.

The patch also modifies usb-storage to set the new flag bits for all
USB devices and targets, and to stop adjusting the scsi_level value.

Historically we have seen that USB mass-storage devices often don't
support VPD pages or REPORT LUNS properly.  Until now we have avoided
these things by setting the scsi_level to SCSI_2 for all USB devices.
But this has the side effect of storing the LUN bits into the second
byte of each CDB, and now we have a report of a device which doesn't
like that.  The best solution is to stop abusing scsi_level and
instead have separate flags for VPD pages and REPORT LUNS.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NPerry Wagle <wagle@mac.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09b6b51b