10 Sep, 2005

4 commits

  • 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: Christoph Hellwig
    Signed-off-by: James Bottomley

    Christoph Hellwig
     
  • 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: Douglas Gilbert
    Acked-by: Jens Axboe
    Signed-off-by: James Bottomley

    Douglas Gilbert
     
  • 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
    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: Douglas Gilbert
    Signed-off-by: James Bottomley

    Douglas Gilbert
     
  • 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: James Bottomley

    James Bottomley
     

09 Sep, 2005

4 commits

  • From: Alan Stern

    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: Alan Stern

    Rejections fixed up and
    Signed-off-by: James Bottomley

    James Bottomley
     
  • 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: Neil Brown
    Signed-off-by: James Bottomley

    Neil Brown
     
  • 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: Alan Stern
    Signed-off-by: James Bottomley

    Alan Stern
     
  • 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: Alan Stern
    Signed-off-by: James Bottomley

    Alan Stern
     

08 Sep, 2005

32 commits