1. 09 Sep, 2005 7 commits
    • 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
  2. 08 Sep, 2005 27 commits
  3. 07 Sep, 2005 6 commits