1. 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
  2. 19 Feb, 2012 2 commits
  3. 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
  4. 08 Jan, 2012 1 commit
  5. 30 Oct, 2011 1 commit
  6. 29 Aug, 2011 1 commit
  7. 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
  8. 31 Mar, 2011 1 commit
  9. 23 Mar, 2011 1 commit
  10. 22 Mar, 2011 1 commit
  11. 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
  12. 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
  13. 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
  14. 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
  15. 22 Dec, 2010 2 commits
    • 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
    • Jens Axboe's avatar
      Revert "sd: implement sd_check_events()" · fcc57045
      Jens Axboe authored
      This reverts commit c8d2e937.
      
      We run into merging problems with the SCSI tree, revert this one
      so it can be handled by a postmerge tree there.
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      fcc57045
  16. 21 Dec, 2010 2 commits
    • Luben Tuikov's avatar
      [SCSI] Retrieve the Caching mode page · 24d720b7
      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
      Signed-off-by: default avatarLuben Tuikov <ltuikov@yahoo.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      24d720b7
    • Alan Stern's avatar
      [SCSI] sd: improve logic and efficiecy of media-change detection · 3ff5588d
      Alan Stern authored
      This patch (as1415) improves the formerly incomprehensible logic in
      sd_media_changed() (the current code refers to "changed" as a state,
      whereas in fact it is a relation between two states).  It also adds a
      big comment so that everyone can understand what is really going on.
      
      The patch also improves efficiency by not reporting a media change
      when no medium was ever present.  If no medium was present the last
      time we checked and there's still no medium, it's not necessary to
      tell the caller that a change occurred.  Doing so merely causes the
      caller to attempt to revalidate a non-existent disk, which is a waste
      of time.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      3ff5588d
  17. 16 Dec, 2010 2 commits
    • Tejun Heo's avatar
      sd: implement sd_check_events() · c8d2e937
      Tejun Heo authored
      Replace sd_media_change() with sd_check_events().  sd used to set the
      changed state whenever the device is not ready, which can cause event
      loop while the device is not ready.  Media presence handling code is
      changed such that the changed state is set iff the media presence
      actually changes.  UA still always sets the changed state and
      NOT_READY always (at least where it used to set ->changed) clears
      media presence, so no event is lost.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      c8d2e937
    • Tejun Heo's avatar
      scsi: replace sr_test_unit_ready() with scsi_test_unit_ready() · 9f8a2c23
      Tejun Heo authored
      The usage of TUR has been confusing involving several different
      commits updating different parts over time.  Currently, the only
      differences between scsi_test_unit_ready() and sr_test_unit_ready()
      are,
      
      * scsi_test_unit_ready() also sets sdev->changed on NOT_READY.
      
      * scsi_test_unit_ready() returns 0 if TUR ended with UNIT_ATTENTION or
        NOT_READY.
      
      Due to the above two differences, sr is using its own
      sr_test_unit_ready(), but sd - the sole user of the above extra
      handling - doesn't even need them.
      
      Where scsi_test_unit_ready() is used in sd_media_changed(), the code
      is looking for device ready w/ media present state which is true iff
      TUR succeeds w/o sense data or UA, and when the device is not ready
      for whatever reason sd_media_changed() explicitly marks media as
      missing so there's no reason to set sdev->changed automatically from
      scsi_test_unit_ready() on NOT_READY.
      
      Drop both special handlings from scsi_test_unit_ready(), which makes
      it equivalant to sr_test_unit_ready(), and replace
      sr_test_unit_ready() with scsi_test_unit_ready().  Also, drop the
      unnecessary explicit NOT_READY check from sd_media_changed().
      Checking return value is enough for testing device readiness.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      9f8a2c23
  18. 17 Nov, 2010 1 commit
  19. 25 Oct, 2010 1 commit
  20. 22 Oct, 2010 1 commit
    • Hans de Goede's avatar
      scsi/sd: add a no_read_capacity_16 scsi_device flag · 5ce524bd
      Hans de Goede authored
      I seem to have a knack for digging up buggy usb devices which don't work
      with Linux, and I'm crazy enough to try to make them work.  So this time a
      friend of mine asked me to get an mp4 player (an mp3 player which can play
      videos on a small screen) to work with Linux.
      
      It is based on the well known rockbox chipset for which we already have an
      unusual devs entries to work around some of its bugs.  But this model
      comes with an additional twist.
      
      This model chokes on read_capacity_16 calls.  Now normally we don't make
      those calls, but this model comes with an sdcard slot and when there is no
      card in there (and shipped from the factory there is none), it reports a
      size of 0.  However this time the programmers actually got the
      read_capacity_10 response right!  So they substract one from the size as
      stored internally in the mp3 player before reporting it back, resulting in
      an answer of ...  0xffffffff sectors, causing sd.c to try a
      read_capacity_16, on which the device crashes.
      
      This patch adds a flag to scsi_device to indicate that a a device cannot
      handle read_capacity_16, and when this flag is set if a device reports an
      lba of 0xffffffff as answer to a read_capacity_10, assumes it tries to
      report a size of 0.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5ce524bd
  21. 11 Oct, 2010 1 commit
  22. 07 Oct, 2010 1 commit
    • Michael Reed's avatar
      [SCSI] sd name space exhaustion causes system hang · 1a03ae0f
      Michael Reed authored
      Following a site power outage which re-enabled all the ports on my FC
      switches, my system subsequently booted with far too many luns!  I had
      let it run hoping it would make multi-user.  It didn't.  :(  It hung solid
      after exhausting the last sd device, sdzzz, and attempting to create sdaaaa
      and beyond.  I was unable to get a dump.
      
      Discovered using a 2.6.32.13 based system.
      
      correct this by detecting when the last index is utilized and failing
      the sd probe of the device.  Patch applies to scsi-misc-2.6.
      Signed-off-by: default avatarMichael Reed <mdr@sgi.com>
      Cc: Stable Tree <stable@kernel.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      1a03ae0f
  23. 17 Sep, 2010 1 commit
  24. 10 Sep, 2010 2 commits
    • Tejun Heo's avatar
      block: deprecate barrier and replace blk_queue_ordered() with blk_queue_flush() · 4913efe4
      Tejun Heo authored
      Barrier is deemed too heavy and will soon be replaced by FLUSH/FUA
      requests.  Deprecate barrier.  All REQ_HARDBARRIERs are failed with
      -EOPNOTSUPP and blk_queue_ordered() is replaced with simpler
      blk_queue_flush().
      
      blk_queue_flush() takes combinations of REQ_FLUSH and FUA.  If a
      device has write cache and can flush it, it should set REQ_FLUSH.  If
      the device can handle FUA writes, it should also set REQ_FUA.
      
      All blk_queue_ordered() users are converted.
      
      * ORDERED_DRAIN is mapped to 0 which is the default value.
      * ORDERED_DRAIN_FLUSH is mapped to REQ_FLUSH.
      * ORDERED_DRAIN_FLUSH_FUA is mapped to REQ_FLUSH | REQ_FUA.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Alasdair G Kergon <agk@redhat.com>
      Cc: Pierre Ossman <drzeus@drzeus.cx>
      Cc: Stefan Weinhuber <wein@de.ibm.com>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      4913efe4
    • Tejun Heo's avatar
      block: kill QUEUE_ORDERED_BY_TAG · 6958f145
      Tejun Heo authored
      Nobody is making meaningful use of ORDERED_BY_TAG now and queue
      draining for barrier requests will be removed soon which will render
      the advantage of tag ordering moot.  Kill ORDERED_BY_TAG.  The
      following users are affected.
      
      * brd: converted to ORDERED_DRAIN.
      * virtio_blk: ORDERED_TAG path was already marked deprecated.  Removed.
      * xen-blkfront: ORDERED_TAG case dropped.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      6958f145
  25. 07 Sep, 2010 1 commit
  26. 05 Sep, 2010 1 commit
    • Mike Christie's avatar
      [SCSI] scsi/block: increase flush/sync timeout · e3b3e624
      Mike Christie authored
      We have been seeing the flush request timeout with a wide
      range of hardware from tgt+iser to FC targets from a major vendor.
      
      After discussions about if the value should be configurable and
      what the best value should be, this patch just increases the flush/sync
      cache timeout to 1 minute. 2 minutes was determined to be too long, and
      making it configurable was troublesome for users.
      
      This patch was made over Linus's tree. It is not made over scsi-misc
      or scsi-rc-fixes, because Linus's had block layer changes that my
      patch was built over.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Acked-by: default avatarJens Axboe <jaxboe@fusionio.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      e3b3e624
  27. 02 Sep, 2010 1 commit
  28. 11 Aug, 2010 1 commit
    • H Hartley Sweeten's avatar
      scsi/sd.c: quiet all sparse noise · 439d77f7
      H Hartley Sweeten authored
      In sd_store_cache_type the symbol 'len' is declared twice.  Remove the
      second declaration to quiet the following sparse warning.
      
      warning: symbol 'len' shadows an earlier one
      
      In sd_probe the variable 'index' is declared as a u32.  This variable is
      used in a call to ida_get_new which is expecting an int *.  Make the
      variable an int to quiet the following sparse warning.
      
      warning: incorrect type in argument 2 (different signedness)
      
      There are 4 symbols in the file that are not exported and produce
      the following sparse warnings.
      
      warning: symbol 'sd_cdb_cache' was not declared. Should it be static?
      warning: symbol 'sd_cdb_pool' was not declared. Should it be static?
      warning: symbol 'sd_read_protection_type' was not declared. Should it be static?
      warning: symbol 'sd_read_app_tag_own' was not declared. Should it be static?
      
      Make them static to quiet the warnings.
      Signed-off-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Cc: James E.J. Bottomley <James.Bottomley@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      439d77f7
  29. 07 Aug, 2010 4 commits
    • FUJITA Tomonori's avatar
      scsi: use REQ_TYPE_FS for flush request · e96f6abe
      FUJITA Tomonori authored
      scsi-ml uses REQ_TYPE_BLOCK_PC for flush requests from file
      systems. The definition of REQ_TYPE_BLOCK_PC is that we don't retry
      requests even when we can (e.g. UNIT ATTENTION) and we send the
      response to the callers (then the callers can decide what they want).
      We need a workaround such as the commit
      77a42297 to retry BLOCK_PC flush
      requests. We will need the similar workaround for discard requests too
      since SCSI-ml handle them as BLOCK_PC internally.
      
      This uses REQ_TYPE_FS for flush requests from file systems instead of
      REQ_TYPE_BLOCK_PC.
      
      scsi-ml retries only REQ_TYPE_FS requests that have data to
      transfer when we can retry them (e.g. UNIT_ATTENTION). However, we
      also need to retry REQ_TYPE_FS requests without data because the
      callers don't.
      
      This also changes scsi_check_sense() to retry all the REQ_TYPE_FS
      requests when appropriate. Thanks to scsi_noretry_cmd(),
      REQ_TYPE_BLOCK_PC requests don't be retried as before.
      
      Note that basically, this reverts the commit
      77a42297 since now we use REQ_TYPE_FS
      for flush requests.
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      e96f6abe
    • FUJITA Tomonori's avatar
      scsi: convert discard to REQ_TYPE_FS from REQ_TYPE_BLOCK_PC · 6a32a8ae
      FUJITA Tomonori authored
      Jens, any reason why this isn't included in your for-2.6.36 yet?
      
      =
      From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Subject: [PATCH resend] scsi: convert discard to REQ_TYPE_FS from REQ_TYPE_BLOCK_PC
      
      The block layer (file systems) sends discard requests as REQ_TYPE_FS
      (the role of REQ_TYPE_FS is that setting up commands and interpreting
      the results). But SCSI-ml treats discard requests as
      REQ_TYPE_BLOCK_PC.
      
      scsi-ml can handle discard requests as REQ_TYPE_FS
      easily. scsi_setup_discard_cmnd() sets up struct request and the bio
      nicely. Only remaining issue is that discard requests can't be
      completed partially so we need to modify sd_done.
      
      This conversion also fixes the problem that discard requests aren't
      retried when possible (e.g. UNIT ATTENTION).
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      6a32a8ae
    • Arnd Bergmann's avatar
      scsi/sd: remove big kernel lock · 409f3499
      Arnd Bergmann authored
      Every user of the BKL in the sd driver is the
      result of the pushdown from the block layer
      into the open/close/ioctl functions.
      
      The only place that used to rely on the BKL is
      the sdkp->openers variable, which gets converted
      into an atomic_t.
      
      Nothing else seems to rely on the BKL, since the
      functions do not touch global data without holding
      another lock, and the open/close functions are
      still protected from concurrent execution using
      the bdev->bd_mutex.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: linux-scsi@vger.kernel.org
      Cc: "James E.J. Bottomley" <James.Bottomley@suse.de>
      Acked-by: default avatarChristoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      409f3499
    • Arnd Bergmann's avatar
      block: push down BKL into .open and .release · 6e9624b8
      Arnd Bergmann authored
      The open and release block_device_operations are currently
      called with the BKL held. In order to change that, we must
      first make sure that all drivers that currently rely
      on this have no regressions.
      
      This blindly pushes the BKL into all .open and .release
      operations for all block drivers to prepare for the
      next step. The drivers can subsequently replace the BKL
      with their own locks or remove it completely when it can
      be shown that it is not needed.
      
      The functions blkdev_get and blkdev_put are the only
      remaining users of the big kernel lock in the block
      layer, besides a few uses in the ioctl code, none
      of which need to serialize with blkdev_{get,put}.
      
      Most of these two functions is also under the protection
      of bdev->bd_mutex, including the actual calls to
      ->open and ->release, and the common code does not
      access any global data structures that need the BKL.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarChristoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      6e9624b8