1. 03 Jul, 2013 1 commit
  2. 07 May, 2013 1 commit
  3. 06 May, 2013 2 commits
  4. 02 May, 2013 1 commit
    • James Bottomley's avatar
      [SCSI] sd: fix array cache flushing bug causing performance problems · 39c60a09
      James Bottomley authored
      Some arrays synchronize their full non volatile cache when the sd driver sends
      a SYNCHRONIZE CACHE command.  Unfortunately, they can have Terrabytes of this
      and we send a SYNCHRONIZE CACHE for every barrier if an array reports it has a
      writeback cache.  This leads to massive slowdowns on journalled filesystems.
      
      The fix is to allow userspace to turn off the writeback cache setting as a
      temporary measure (i.e. without doing the MODE SELECT to write it back to the
      device), so even though the device reported it has a writeback cache, the
      user, knowing that the cache is non volatile and all they care about is
      filesystem correctness, can turn that bit off in the kernel and avoid the
      performance ruinous (and safety irrelevant) SYNCHRONIZE CACHE commands.
      
      The way you do this is add a 'temporary' prefix when performing the usual
      cache setting operations, so
      
      echo temporary write through > /sys/class/scsi_disk/<disk>/cache_type
      Reported-by: default avatarRic Wheeler <rwheeler@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      39c60a09
  5. 30 Nov, 2012 2 commits
    • Aaron Lu's avatar
      [SCSI] sd: update sd to use the new pm callbacks · 691e3d31
      Aaron Lu authored
      Update sd driver to use the callbacks defined in dev_pm_ops.
      
      sd_freeze is NULL, the bus level callback has taken care of quiescing
      the device so there should be nothing needs to be done here.
      Consequently, sd_thaw is not needed here either.
      
      suspend, poweroff and runtime suspend share the same routine sd_suspend,
      which will sync flush and then stop the drive, this is the same as before.
      
      resume, restore and runtime resume share the same routine sd_resume,
      which will start the drive by putting it into active power state, this
      is also the same as before.
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      691e3d31
    • Aaron Lu's avatar
      [SCSI] sd: put to stopped power state when runtime suspend · a0147563
      Aaron Lu authored
      When device is runtime suspended, put it to stopped power state to save
      some power.
      
      This will also make the behaviour consistent with what the scsi_pm.c
      thinks about sd as the comment says:
      sd treats runtime suspend, system suspend and system hibernate identical.
      With this patch, it is now identical.
      And sd_shutdown will also do nothing when it finds the device has been
      runtime suspended, if we do not spin down the disk in runtime suspend
      by putting it into stopped power state, the disk will be shut down
      incorrectly.
      And the the same problem can be solved for runtime power off after
      runtime suspended case by this change.
      
      With the current runtime scheme for disk, it will only be runtime
      suspended when no process opens the disk, so this shouldn't happen a
      lot, which makes it acceptable to spin down the disk when runtime
      suspended. If some day a more aggressive runtime scheme is used, like
      the 'request based runtime pm for disk' that Alan Stern and Lin Ming
      has been working, we can introduce some policy to control this. But for
      now, make it simple and correct by spinning down the disk.
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      a0147563
  6. 26 Nov, 2012 2 commits
  7. 13 Nov, 2012 2 commits
    • Martin K. Petersen's avatar
      [SCSI] sd: Implement support for WRITE SAME · 5db44863
      Martin K. Petersen authored
      Implement support for WRITE SAME(10) and WRITE SAME(16) in the SCSI disk
      driver.
      
       - We set the default maximum to 0xFFFF because there are several
         devices out there that only support two-byte block counts even with
         WRITE SAME(16). We only enable transfers bigger than 0xFFFF if the
         device explicitly reports MAXIMUM WRITE SAME LENGTH in the BLOCK
         LIMITS VPD.
      
       - max_write_same_blocks can be overriden per-device basis in sysfs.
      
       - The UNMAP discovery heuristics remain unchanged but the discard
         limits are tweaked to match the "real" WRITE SAME commands.
      
       - In the error handling logic we now distinguish between WRITE SAME
         with and without UNMAP set.
      
      The discovery process heuristics are:
      
       - If the device reports a SCSI level of SPC-3 or greater we'll issue
         READ SUPPORTED OPERATION CODES to find out whether WRITE SAME(16) is
         supported. If that's the case we will use it.
      
       - If the device supports the block limits VPD and reports a MAXIMUM
         WRITE SAME LENGTH bigger than 0xFFFF we will use WRITE SAME(16).
      
       - Otherwise we will use WRITE SAME(10) unless the target LBA is beyond
         0xFFFFFFFF or the block count exceeds 0xFFFF.
      
       - no_write_same is set for ATA, FireWire and USB.
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: default avatarMike Snitzer <snitzer@redhat.com>
      Reviewed-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      5db44863
    • Martin K. Petersen's avatar
      [SCSI] sd: Permit merged discard requests · 26e85fcd
      Martin K. Petersen authored
      Support requests with more than one bio payload for discards. The total
      number of bytes to be discarded is stored in req->__data_len and used in
      sd_done() to complete the I/O.
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      26e85fcd
  8. 24 Sep, 2012 3 commits
  9. 20 Jul, 2012 2 commits
  10. 16 Jul, 2012 1 commit
  11. 22 Jun, 2012 1 commit
    • Alan Stern's avatar
      SCSI & usb-storage: add try_rc_10_first flag · 6a0bdffa
      Alan Stern authored
      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: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarHans 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: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a0bdffa
  12. 17 May, 2012 1 commit
    • Dan Williams's avatar
      [SCSI] sd: limit the scope of the async probe domain · a7a20d10
      Dan Williams authored
      sd injects and synchronizes probe work on the global kernel-wide domain.
      This runs into conflict with PM that wants to perform resume actions in
      async context:
      
      [  494.237079] INFO: task kworker/u:3:554 blocked for more than 120 seconds.
      [  494.294396] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  494.360809] kworker/u:3     D 0000000000000000     0   554      2 0x00000000
      [  494.420739]  ffff88012e4d3af0 0000000000000046 ffff88013200c160 ffff88012e4d3fd8
      [  494.484392]  ffff88012e4d3fd8 0000000000012500 ffff8801394ea0b0 ffff88013200c160
      [  494.548038]  ffff88012e4d3ae0 00000000000001e3 ffffffff81a249e0 ffff8801321c5398
      [  494.611685] Call Trace:
      [  494.632649]  [<ffffffff8149dd25>] schedule+0x5a/0x5c
      [  494.674687]  [<ffffffff8104b968>] async_synchronize_cookie_domain+0xb6/0x112
      [  494.734177]  [<ffffffff810461ff>] ? __init_waitqueue_head+0x50/0x50
      [  494.787134]  [<ffffffff8131a224>] ? scsi_remove_target+0x48/0x48
      [  494.837900]  [<ffffffff8104b9d9>] async_synchronize_cookie+0x15/0x17
      [  494.891567]  [<ffffffff8104ba49>] async_synchronize_full+0x54/0x70  <-- here we wait for async contexts to complete
      [  494.943783]  [<ffffffff8104b9f5>] ? async_synchronize_full_domain+0x1a/0x1a
      [  495.002547]  [<ffffffffa00114b1>] sd_remove+0x2c/0xa2 [sd_mod]
      [  495.051861]  [<ffffffff812fe94f>] __device_release_driver+0x86/0xcf
      [  495.104807]  [<ffffffff812fe9bd>] device_release_driver+0x25/0x32  <-- here we take device_lock()
      
      [  853.511341] INFO: task kworker/u:4:549 blocked for more than 120 seconds.
      [  853.568693] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  853.635119] kworker/u:4     D ffff88013097b5d0     0   549      2 0x00000000
      [  853.695129]  ffff880132773c40 0000000000000046 ffff880130790000 ffff880132773fd8
      [  853.758990]  ffff880132773fd8 0000000000012500 ffff88013288a0b0 ffff880130790000
      [  853.822796]  0000000000000246 0000000000000040 ffff88013097b5c8 ffff880130790000
      [  853.886633] Call Trace:
      [  853.907631]  [<ffffffff8149dd25>] schedule+0x5a/0x5c
      [  853.949670]  [<ffffffff8149cc44>] __mutex_lock_common+0x220/0x351
      [  854.001225]  [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4
      [  854.049082]  [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4
      [  854.097011]  [<ffffffff8149ce48>] mutex_lock_nested+0x2f/0x36   <-- here we wait for device_lock()
      [  854.145591]  [<ffffffff81304bd7>] device_resume+0x58/0x1c4
      [  854.192066]  [<ffffffff81304d61>] async_resume+0x1e/0x45
      [  854.237019]  [<ffffffff8104bc93>] async_run_entry_fn+0xc6/0x173  <-- ...while running in async context
      
      Provide a 'scsi_sd_probe_domain' so that async probe actions actions can
      be flushed without regard for the state of PM, and allow for the resume
      path to handle devices that have transitioned from SDEV_QUIESCE to
      SDEV_DEL prior to resume.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      [alan: uplevel scsi_sd_probe_domain, clarify scsi_device_resume]
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      [jejb: remove unneeded config guards in include file]
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      a7a20d10
  13. 27 Mar, 2012 1 commit
  14. 19 Mar, 2012 1 commit
    • Lan Tianyu's avatar
      [SCSI] sd: Add runtime pm in the sd_check_events() · 4e2247b2
      Lan Tianyu authored
      The sd_check_event() will be called periodly even when the device is in the
      suspended status to check media event. The scsi_test_unit_ready() in the
      sd_check_event() will issue scsi cmd request. Issuing scsi request when the
      device is in the suspeneded status will cause problem. For example, when a usb
      flash disk in the suspended status, scsi_test_unit_ready() issues a scsi
      request. The request will be returned as failed because the usb device is not
      active. The patch adds scsi_autopm_get_device() and scsi_autopm_put_device()
      around scsi_test_unit_ready() in the sd_check_event() to resolve such problem.
      Signed-off-by: default avatarLan Tianyu <tianyu.lan@intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      4e2247b2
  15. 19 Feb, 2012 2 commits
  16. 08 Feb, 2012 1 commit
    • Alan Stern's avatar
      SCSI & usb-storage: add flags for VPD pages and REPORT LUNS · 09b6b51b
      Alan Stern authored
      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: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarPerry Wagle <wagle@mac.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09b6b51b
  17. 14 Jan, 2012 2 commits
    • Paolo Bonzini's avatar
      block: fail SCSI passthrough ioctls on partition devices · 0bfc96cb
      Paolo Bonzini authored
      Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
      will pass the command to the underlying block device.  This is
      well-known, but it is also a large security problem when (via Unix
      permissions, ACLs, SELinux or a combination thereof) a program or user
      needs to be granted access only to part of the disk.
      
      This patch lets partitions forward a small set of harmless ioctls;
      others are logged with printk so that we can see which ioctls are
      actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
      Of course it was being sent to a (partition on a) hard disk, so it would
      have failed with ENOTTY and the patch isn't changing anything in
      practice.  Still, I'm treating it specially to avoid spamming the logs.
      
      In principle, this restriction should include programs running with
      CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
      /dev/sdb, it still should not be able to read/write outside the
      boundaries of /dev/sda2 independent of the capabilities.  However, for
      now programs with CAP_SYS_RAWIO will still be allowed to send the
      ioctls.  Their actions will still be logged.
      
      This patch does not affect the non-libata IDE driver.  That driver
      however already tests for bd != bd->bd_contains before issuing some
      ioctl; it could be restricted further to forbid these ioctls even for
      programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.
      
      Cc: linux-scsi@vger.kernel.org
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: James Bottomley <JBottomley@parallels.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [ Make it also print the command name when warning - Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0bfc96cb
    • Paolo Bonzini's avatar
      block: add and use scsi_blk_cmd_ioctl · 577ebb37
      Paolo Bonzini authored
      Introduce a wrapper around scsi_cmd_ioctl that takes a block device.
      
      The function will then be enhanced to detect partition block devices
      and, in that case, subject the ioctls to whitelisting.
      
      Cc: linux-scsi@vger.kernel.org
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: James Bottomley <JBottomley@parallels.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      577ebb37
  18. 08 Jan, 2012 1 commit
  19. 30 Oct, 2011 1 commit
  20. 29 Aug, 2011 1 commit
  21. 24 May, 2011 2 commits
    • Luben Tuikov's avatar
      [SCSI] Retrieve the Caching mode page (version 2) · 0bcaa111
      Luben Tuikov authored
      Some kernel transport drivers unconditionally disable
      retrieval of the Caching mode page. One such for example is
      the BBB/CBI transport over USB. Such a restraint is too
      harsh as some devices do support the Caching mode
      page. Unconditionally enabling the retrieval of this mode
      page over those transports at their transport code level may
      result in some devices failing and becoming unusable.
      
      This patch implements a method of retrieving the Caching
      mode page without unconditionally enabling it in the
      transports which unconditionally disable it. The idea is to
      ask for all supported pages, page code 0x3F, and then search
      for the Caching mode page in the mode parameter data
      returned. The sd driver already asks for all the mode pages
      supported by the attached device by setting the page code to
      0x3F in order to find out if the media is write protected by
      reading the WP bit in the Device Specific Parameter
      field. It then attempts to retrieve only the Caching mode
      page by setting the page code to 8 and actually attempting
      to retrieve it if and only if the transport allows it.
      
      The method implemented here is that if the transport doesn't
      allow retrieval of the Caching mode page and the device is
      not RBC, then we ask for all pages supported by setting the
      page code to 0x3F (similarly to how the WP bit is retrieved
      above), and then we search for the Caching mode page in the
      mode parameter data returned.
      
      With this patch, devices over SATA, report this (no change):
      
      Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
      Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
      Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
      Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
      Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
      
      Smart devices report their Caching mode page. This is a
      change where we'd previously see the kernel making
      assumption about the device's cache being write-through:
      
      Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
      Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
      Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
      Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
      Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
      
      And "dumb" devices over BBB, are correctly shown not to
      support reporting the Caching mode page:
      
      Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
      Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
      Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
      Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
      Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
      
      Version 2 adds this:
      
      Some devices don't support page code 0x3F, and others require a
      fixed transfer length of 192 bytes. This single commit includes a
      patch by Alan Stern which fixes this.
      Reported-and-tested-by: default avatarRichard Senior <richard@r-senior.demon.co.uk>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarLuben Tuikov <ltuikov@yahoo.com>
      Signed-off-by: default avatarJames Bottomley <jbottomley@parallels.com>
      0bcaa111
    • Martin K. Petersen's avatar
      [SCSI] sd: Unmap discard alignment needs to be converted to bytes · 2a8cfad0
      Martin K. Petersen authored
      The block layer discard alignment is reported in bytes, not in units of
      the logical block size.
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJames Bottomley <jbottomley@parallels.com>
      2a8cfad0
  22. 31 Mar, 2011 1 commit
  23. 23 Mar, 2011 1 commit
  24. 22 Mar, 2011 1 commit
  25. 14 Mar, 2011 1 commit
    • Martin K. Petersen's avatar
      [SCSI] sd: Logical Block Provisioning update · c98a0eb0
      Martin K. Petersen authored
      SBC3r26 contains many changes to the Logical Block Provisioning
      interfaces (formerly known as Thin Provisioning ditto). This patch
      implements support for both the old and new schemes using the same
      heuristic as before (whether the LBP VPD page is present).
      
      The new code also allows the provisioning mode (i.e. choice of command)
      to be overridden on a per-device basis via sysfs. Two additional modes
      are supported in this version:
      
       - WRITE SAME(10) with the UNMAP bit set
      
       - WRITE SAME(10) without the UNMAP bit set. This allows us to support
         devices that predate the TP/LBP enhancements in SBC3 and which work
         by way zero-detection
      
      Switching between modes has been consolidated in a helper function that
      also updates the block layer topology according to the limitations of
      the chosen command.
      
      I experimented with trying WRITE SAME(16) if UNMAP fails, WRITE SAME(10)
      if WRITE SAME(16) fails, etc. but found several devices that got
      cranky. So for now we'll disable discard if one of the commands
      fail. The user still has the option of selecting a different mode in
      sysfs.
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      c98a0eb0
  26. 14 Jan, 2011 2 commits
    • Tejun Heo's avatar
      [SCSI] sd,sr: kill compat SDEV_MEDIA_CHANGE event · f4013c38
      Tejun Heo authored
      SDEV_MEDIA_CHANGE event was first added by commit a341cd0f (SCSI: add
      asynchronous event notification API) for SATA AN support and then
      extended to cover generic media change events by commit 285e9670
      ([SCSI] sr,sd: send media state change modification events).
      
      This event was mapped to block device in userland with all properties
      stripped to simulate CHANGE event on the block device, which, in turn,
      was used to trigger further userspace action on media change.
      
      The recent addition of disk event framework kept this event for
      backward compatibility but it turns out to be unnecessary and causes
      erratic and inefficient behavior.  The new disk event generates proper
      events on the block devices and the compat events are mapped to block
      device with all properties stripped, so the block device ends up
      generating multiple duplicate events for single actual event.
      
      This patch removes the compat event generation from both sr and sd as
      suggested by Kay Sievers.  Both existing and newer versions of udev
      and the associated tools will behave better with the removal of these
      events as they from the beginning were expecting events on the block
      devices.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      f4013c38
    • Tejun Heo's avatar
      [SCSI] sd: implement sd_check_events() · 2bae0093
      Tejun Heo authored
      Replace sd_media_change() with sd_check_events().
      
      * Move media removed logic into set_media_not_present() and
        media_not_present() and set sdev->changed iff an existing media is
        removed or the device indicates UNIT_ATTENTION.
      
      * Make sd_check_events() sets sdev->changed if previously missing
        media becomes present.
      
      * Event is reported only if sdev->changed is set.
      
      This makes media presence event reported if scsi_disk->media_present
      actually changed or the device indicated UNIT_ATTENTION.  For backward
      compatibility, SDEV_EVT_MEDIA_CHANGE is generated each time
      sd_check_events() detects media change event.
      
      [jejb: fix boot failure]
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarJens Axboe <jaxboe@fusionio.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      2bae0093
  27. 04 Jan, 2011 1 commit
    • Tejun Heo's avatar
      [SCSI] sd,sr: kill compat SDEV_MEDIA_CHANGE event · 140e3008
      Tejun Heo authored
      SDEV_MEDIA_CHANGE event was first added by commit a341cd0f (SCSI: add
      asynchronous event notification API) for SATA AN support and then
      extended to cover generic media change events by commit 285e9670
      ([SCSI] sr,sd: send media state change modification events).
      
      This event was mapped to block device in userland with all properties
      stripped to simulate CHANGE event on the block device, which, in turn,
      was used to trigger further userspace action on media change.
      
      The recent addition of disk event framework kept this event for
      backward compatibility but it turns out to be unnecessary and causes
      erratic and inefficient behavior.  The new disk event generates proper
      events on the block devices and the compat events are mapped to block
      device with all properties stripped, so the block device ends up
      generating multiple duplicate events for single actual event.
      
      This patch removes the compat event generation from both sr and sd as
      suggested by Kay Sievers.  Both existing and newer versions of udev
      and the associated tools will behave better with the removal of these
      events as they from the beginning were expecting events on the block
      devices.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      140e3008
  28. 28 Dec, 2010 1 commit
    • Tejun Heo's avatar
      [SCSI] sd: implement sd_check_events() · eface65c
      Tejun Heo authored
      Replace sd_media_change() with sd_check_events().
      
      * Move media removed logic into set_media_not_present() and
        media_not_present() and set sdev->changed iff an existing media is
        removed or the device indicates UNIT_ATTENTION.
      
      * Make sd_check_events() sets sdev->changed if previously missing
        media becomes present.
      
      * Event is reported only if sdev->changed is set.
      
      This makes media presence event reported if scsi_disk->media_present
      actually changed or the device indicated UNIT_ATTENTION.  For backward
      compatibility, SDEV_EVT_MEDIA_CHANGE is generated each time
      sd_check_events() detects media change event.
      
      [jejb: fix boot failure]
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarJens Axboe <jaxboe@fusionio.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      eface65c
  29. 22 Dec, 2010 1 commit
    • James Bottomley's avatar
      [SCSI] fix medium error problems with some arrays which can cause data corruption · a8733c7b
      James Bottomley authored
      Our current handling of medium error assumes that data is returned up
      to the bad sector.  This assumption holds good for all disk devices,
      all DIF arrays and most ordinary arrays.  However, an LSI array engine
      was recently discovered which reports a medium error without returning
      any data.  This means that when we report good data up to the medium
      error, we've reported junk originally in the buffer as good.  Worse,
      if the read consists of requested data plus a readahead, and the error
      occurs in readahead, we'll just strip off the readahead and report
      junk up to userspace as good data with no error.
      
      The fix for this is to have the error position computation take into
      account the amount of data returned by the driver using the scsi
      residual data.  Unfortunately, not every driver fills in this data,
      but for those who don't, it's set to zero, which means we'll think a
      full set of data was transferred and the behaviour will be identical
      to the prior behaviour of the code (believe the buffer up to the error
      sector).  All modern drivers seem to set the residual, so that should
      fix up the LSI failure/corruption case.
      Reported-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Cc: Stable Tree <stable@kernel.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      a8733c7b