1. 10 Sep, 2005 5 commits
  2. 09 Sep, 2005 10 commits
    • James Bottomley's avatar
    • adam radford's avatar
      [SCSI] 3ware 9000: handle use_sg != 0 for emulated commands · d327d082
      adam radford authored
      The attached patch updates the driver for the 3ware 9000 series to do
      the following:
      
      - Correctly handle single sgl's with use_sg = 1.
      
      This is needed with the latest scsi-block-2.6 merge otherwise the 3w-9xxx
      driver will not work.  I tested the patch James sent a few weeks back to fix
      this, and it had a bug where the request_buffer was accessed in
      twa_scsiop_execute_scsi_complete() when it was invalid.  This is a corrected
      variation of that patch.
      Signed-off-by: default avatarAdam Radford <linuxraid@amcc.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      d327d082
    • Christoph Hellwig's avatar
      [SCSI] SAS transport class · c7ebbbce
      Christoph Hellwig authored
      The SAS transport class contains common code to deal with SAS HBAs, an
      aproximated representation of SAS topologies in the driver model,
      and various sysfs attributes to expose these topologies and managment
      interfaces to userspace.
      
      In addition to the basic SCSI core objects this transport class introduces
      two additional intermediate objects:  The SAS PHY as represented by struct
      sas_phy defines an "outgoing" PHY on a SAS HBA or Expander, and the SAS
      remote PHY represented by struct sas_rphy defines an "incoming" PHY on a
      SAS Expander or end device.  Note that this is purely a software concept, the
      underlying hardware for a PHY and a remote PHY is the exactly the same.
      
      There is no concept of a SAS port in this code, users can see what PHYs
      form a wide port based on the port_identifier attribute, which is the same
      for all PHYs in a port.
      
      This submission doesn't handle hot-plug addition or removal of SAS devices
      and thus doesn't do scanning in a workqueue yet, that will be added in
      phase2 after this submission.  In a third phase I will add additional
      managment infrastructure.
      
      I think this submission is ready for 2.6.14, but additional comments are
      of course very welcome.
      
      I'd like to thanks James Smart a lot for his very useful input on the
      design.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      c7ebbbce
    • Douglas Gilbert's avatar
      [SCSI] permit READ DEFECT DATA in block/scsi_ioctl · 942fc2fb
      Douglas Gilbert authored
      The soon to be released smartmontools 5.34 uses the
      READ DEFECT DATA command on SCSI disks. A disk that
      has defect list entries (or worse, an increasing number
      of them) is at risk.
      
      Currently the first invocation of smartctl causes this:
         scsi: unknown opcode 0x37
      message to appear the console and in the log.
      
      The READ DEFECT DATA SCSI command does not change
      the state of a disk. Its opcode (0x37) is valid for
      SBC devices (e.g. disks) and SMC-2 devices (media
      changers) where it is called INITIALIZE STATUS ELEMENT
      WITH RANGE and again doesn't change the external state
      of the device.
      
      Changelog:
        - mark SCSI opcode 0x37 (READ DEFECT DATA) as
          safe_for_read
      Signed-off-by: default avatarDouglas Gilbert <dougg@torque.net>
      Acked-by: default avatarJens Axboe <axboe@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      942fc2fb
    • Douglas Gilbert's avatar
      [SCSI] sg: do not set VM_IO flag on mmap-ed pages · 1c8e71d7
      Douglas Gilbert authored
      Further to the problem discussed in this post:
      http://marc.theaimsgroup.com/?l=linux-scsi&m=112540053711489&w=2
      
      It seems that the sg driver does not need to set the VM_IO flag
      on pages that it memory maps to the user space since they are
      not from the IO space. Ahmed Teirelbar <ahmed.teirelbar@adic.com>
      wants the facility and has tested this patch as I have without
      adverse effects.
      
      The oops protection is still important. Some users really did
      try and use dio transfers from the sg driver to memory mapped
      IO space (on a video capture card if my memory serves) during the
      lk 2.4 series. I'm not sure how successful it was but that will
      now be politely refused in lk 2.6.13+ .
      
      Changelog:
         - set the page flags for sg's reserved buffer mmap-ed
           to the user space to VM_RESERVED (rather than
           VM_RESERVED | VM_IO )
      Signed-off-by: default avatarDouglas Gilbert <dougg@torque.net>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      1c8e71d7
    • James Bottomley's avatar
      [SCSI] SCSI core: fix leakage of scsi_cmnd's · 788ce43a
      James Bottomley authored
      Actually, just one problem and one cosmetic fix:
      
      1) We need to dequeue for the loop and kill case (it seems easiest
      simply to dequeue in the scsi_kill_request() routine)
      2) There's no real need to drop the queue lock.  __scsi_done() is lock
      agnostic, so since there's no requirement, let's just leave it in to
      avoid any locking issues.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      788ce43a
    • James Bottomley's avatar
      [SCSI] SCSI core: fix leakage of scsi_cmnd's · e91442b6
      James Bottomley authored
      From: 	Alan Stern <stern@rowland.harvard.edu>
      
      This patch (as559b) adds a new routine, scsi_unprep_request, which
      gets called every place a request is requeued.  (That includes
      scsi_queue_insert as well as scsi_requeue_command.)  It also changes
      scsi_kill_requests to make it call __scsi_done with result equal to
      DID_NO_CONNECT << 16.  (I'm not sure if it's necessary to call
      scsi_init_cmd_errh here; maybe you can check on that.)  Finally, the
      patch changes the return value from scsi_end_request, to avoid
      returning a stale pointer in the case where the request was requeued.
      Fortunately the return value is used in only place, and the change
      actually simplified it.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      
      Rejections fixed up and
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      e91442b6
    • Neil Brown's avatar
      [SCSI] fix possible deadlock in scsi_lib.c · 286f3e13
      Neil Brown authored
        If a filesystem, while writing out data, decides that it is good
      to issue a cache flush on a SCSI drive (or other 'sd' device), it will
      call blkdev_issue_flush which calls ->issue_flush_fn which is
      scsi_issue_flush_fn.
      This calls sd_issue_flush which calls sd_sync_cache, which calls
      scsi_execute_request.
      This will (as sshdr != NULL) call
          kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL)
      
      If memory is tight, the presence of GFP_KERNEL may cause write
      requests to be sent to some filesystem to free up memory, however if
      that filesystem is waiting for the issue_flush_fn to complete, you
      could get a deadlock.
      
      I wonder if it might be more appropriate to use GFP_NOIO as in the
      following patch.
      
      I wonder if it might be even more appropriate to cope better with a
      kmalloc failure, especially as in this use, sd_sync_cache only will
      use the sense information to print out a more informative error
      message.
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      286f3e13
    • Alan Stern's avatar
      [SCSI] fix callers of scsi_remove_device() who already hold the scan muted · 903f4fed
      Alan Stern authored
      This patch (as544) adds a private entry point to scsi_remove_device, for
      use when callers already own the scan_mutex.  The appropriate callers are
      modified to use the new entry point.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      903f4fed
    • Alan Stern's avatar
      [SCSI] add missing scan mutex to scsi_scan_target() · e517d313
      Alan Stern authored
      This patch (as543) adds a private entry point to scsi_scan_target, for use
      when the caller already owns the scan_mutex, and updates the kerneldoc for
      that routine (which was badly out-of-date).  It converts scsi_scan_channel
      to use the new entry point.  Lastly, it modifies scsi_get_host_dev to make
      it acquire the scan_mutex, necessary since the routine adds a new
      scsi_device even if it doesn't do any actual scanning.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      e517d313
  3. 08 Sep, 2005 25 commits