1. 07 Dec, 2006 1 commit
  2. 25 Nov, 2006 1 commit
    • FUJITA Tomonori's avatar
      [SCSI] export scsi-ml functions needed by tgt_scsi_lib and its LLDs · b58d9154
      FUJITA Tomonori authored
      
      
      This patch contains the needed changes to the scsi-ml for the target
      mode support.
      
      Note, per the last review we moved almost all the fields we added
      to the scsi_cmnd to our internal data structure which we are going
      to try and kill off when we can replace it with support from other
      parts of the kernel.
      
      The one field we left on was the offset variable. This is needed to handle
      the case where the target gets request that is so large that it cannot
      execute it in one dma operation. So max_secotors or a segment limit may
      limit the size of the transfer. In this case our tgt core code will
      break up the command into managable transfers and send them to the
      LLD one at a time. The offset is then used to tell the LLD where in
      the command we are at. Is there another field on the scsi_cmd for
      that?
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      b58d9154
  3. 16 Nov, 2006 1 commit
  4. 15 Nov, 2006 1 commit
    • Christoph Hellwig's avatar
      [SCSI] untangle scsi_prep_fn · 3b003157
      Christoph Hellwig authored
      
      
      I wanted to add some BUG checks to scsi_prep_fn to make sure no one
      sends us a non-sg command, but this function is a horrible mess.
      
      So I decided to detangle the function and document what the valid
      cases are.  While doing that I found that REQ_TYPE_SPECIAL commands
      aren't used by the SCSI layer anymore and we can get rid of the code
      handling them.
      
      The new structure of scsi_prep_fn is:
      
       (1) check if we're allowed to send this command
       (2) big switch on cmd_type.  For the two valid types call into
           a function to set the command up, else error
       (3) code to handle error cases
      
      Because FS and BLOCK_PC commands are handled entirely separate after
      the patch this introduces a tiny amount of code duplication.  This
      improves readabiulity though and will help to avoid the bidi command
      overhead for FS commands so it's a good thing.
      
      I've tested this on both sata and mptsas.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      3b003157
  5. 25 Oct, 2006 1 commit
  6. 01 Oct, 2006 1 commit
  7. 30 Sep, 2006 1 commit
    • Jens Axboe's avatar
      [PATCH] Split struct request ->flags into two parts · 4aff5e23
      Jens Axboe authored
      
      
      Right now ->flags is a bit of a mess: some are request types, and
      others are just modifiers. Clean this up by splitting it into
      ->cmd_type and ->cmd_flags. This allows introduction of generic
      Linux block message types, useful for sending generic Linux commands
      to block devices.
      Signed-off-by: default avatarJens Axboe <axboe@suse.de>
      4aff5e23
  8. 19 Aug, 2006 1 commit
    • Andreas Herrmann's avatar
      [SCSI] limit recursion when flushing shost->starved_list · 04846f25
      Andreas Herrmann authored
      
      
      Attached is a patch that should limit a possible recursion that can
      lead to a stack overflow like follows:
      
      Kernel stack overflow.
      CPU:    3    Not tainted
      Process zfcperp0.0.d819
      (pid: 13897, task: 000000003e0d8cc8, ksp: 000000003499dbb8)
      Krnl PSW : 0404000180000000 000000000030f8b2 (get_device+0x12/0x48)
      Krnl GPRS: 00000000135a1980 000000000030f758 000000003ed6c1e8 0000000000000005
                 0000000000000000 000000000044a780 000000003dbf7000 0000000034e15800
                 000000003621c048 070000003499c108 000000003499c1a0 000000003ed6c000
                 0000000040895000 00000000408ab630 000000003499c0a0 000000003499c0a0
      Krnl Code: a7 fb ff e8 a7 19 00 00 b9 02 00 22 e3 e0 f0 98 00 24 a7 84
      Call Trace:
      ([<000000004089edc2>] scsi_request_fn+0x13e/0x650 [scsi_mod])
       [<00000000002c5ff4>] blk_run_queue+0xd4/0x1a4
       [<000000004089ff8c>] scsi_queue_insert+0x22c/0x2a4 [scsi_mod]
       [<000000004089779a>] scsi_dispatch_cmd+0x8a/0x3d0 [scsi_mod]
       [<000000004089f1ec>] scsi_request_fn+0x568/0x650 [scsi_mod]
      ...
       [<000000004089f1ec>] scsi_request_fn+0x568/0x650 [scsi_mod]
       [<00000000002c5ff4>] blk_run_queue+0xd4/0x1a4
       [<000000004089ff8c>] scsi_queue_insert+0x22c/0x2a4 [scsi_mod]
       [<000000004089779a>] scsi_dispatch_cmd+0x8a/0x3d0 [scsi_mod]
       [<000000004089f1ec>] scsi_request_fn+0x568/0x650 [scsi_mod]
       [<00000000002c5ff4>] blk_run_queue+0xd4/0x1a4
       [<000000004089fa9e>] scsi_run_host_queues+0x196/0x230 [scsi_mod]
       [<00000000409eba28>] zfcp_erp_thread+0x2638/0x3080 [zfcp]
       [<0000000000107462>] kernel_thread_starter+0x6/0xc
       [<000000000010745c>] kernel_thread_starter+0x0/0xc
      <0>Kernel panic - not syncing: Corrupt kernel stack, can't continue.
      
      This stack overflow occurred during tests on s390 using zfcp.
      Recursion depth for this panic was 19.
      
      Usually recursion between blk_run_queue and a request_fn is avoided
      using QUEUE_FLAG_REENTER. But this does not help if the scsi stack
      tries to flush the starved_list of a scsi_host.
      
      Limit recursion depth when flushing the starved_list
      of a scsi_host.
      Signed-off-by: default avatarAndreas Herrmann <aherrman@de.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      04846f25
  9. 09 Jul, 2006 1 commit
    • Christoph Hellwig's avatar
      [SCSI] hide EH backup data outside the scsi_cmnd · 631c228c
      Christoph Hellwig authored
      
      
      Currently struct scsi_cmnd has various fields that are used to backup
      original data after the corresponding fields have been overridden for
      EH commands.  This means drivers can easily get at it and misuse it.
      Due to the old_ naming this doesn't happen for most of them, but two
      that have different names have been used wrong a lot (see previous
      patch).  Another downside is that they unessecarily bloat the scsi_cmnd
      size.
      
      This patch moves them onstack in scsi_send_eh_cmnd to fix those two
      issues aswell as allowing future EH fixes like moving the EH command
      submissions to use SG lists like everything else.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      631c228c
  10. 02 Jul, 2006 1 commit
  11. 28 Jun, 2006 1 commit
    • Brian King's avatar
      [SCSI] scsi: Device scanning oops for offlined devices (resend) · 309bd271
      Brian King authored
      
      
      If a device gets offlined as a result of the Inquiry sent
      during scanning, the following oops can occur. After the
      disk gets put into the SDEV_OFFLINE state, the error handler
      sends back the failed inquiry, which wakes the thread doing
      the scan. This starts a race between the scanning thread
      freeing the scsi device and the error handler calling
      scsi_run_host_queues to restart the host. Since the disk
      is in the SDEV_OFFLINE state, scsi_device_get will still
      work, which results in __scsi_iterate_devices getting
      a reference to the scsi disk when it shouldn't.
      
      The following execution thread causes the oops:
      
      CPU 0 (scan)				CPU 1 (eh)
      
      ---------------------------------------------------------
      scsi_probe_and_add_lun
                              ....
                                              scsi_eh_offline_sdevs
                                              scsi_eh_flush_done_q
      scsi_destroy_sdev
      scsi_device_dev_release
                                              scsi_restart_operations
                                               scsi_run_host_queues
                                                __scsi_iterate_devices
                                                 get_device
      scsi_device_dev_release_usercontext
                                                scsi_run_queue
                                                  <---OOPS--->
      
      The patch fixes this by changing the state of the sdev to SDEV_DEL
      before doing the final put_device, which should prevent the race
      from occurring.
      
      Original oops follows:
      
      Badness in kref_get at lib/kref.c:32
      Call Trace:
      [C00000002F4476D0] [C00000000000EE20] .show_stack+0x68/0x1b0 (unreliable)
      [C00000002F447770] [C00000000037515C] .program_check_exception+0x1cc/0x5a8
      [C00000002F447840] [C00000000000446C] program_check_common+0xec/0x100
       Exception: 700 at .kref_get+0x10/0x28
          LR = .kobject_get+0x20/0x3c
      [C00000002F447B30] [C00000002F447BC0] 0xc00000002f447bc0 (unreliable)
      [C00000002F447BB0] [C000000000254BDC] .get_device+0x20/0x3c
      [C00000002F447C30] [D000000000063188] .scsi_device_get+0x34/0xdc [scsi_mod]
      [C00000002F447CC0] [D0000000000633EC] .__scsi_iterate_devices+0x50/0xbc [scsi_mod]
      [C00000002F447D60] [D00000000006A910] .scsi_run_host_queues+0x34/0x5c [scsi_mod]
      [C00000002F447DF0] [D000000000069054] .scsi_error_handler+0xdb4/0xe44 [scsi_mod]
      [C00000002F447EE0] [C00000000007B4E0] .kthread+0x128/0x178
      [C00000002F447F90] [C000000000025E84] .kernel_thread+0x4c/0x68
      Unable to handle kernel paging request for <7>PCI: Enabling device: (0002:41:01.1), cmd 143
      data at address 0x000001b8
      Faulting instruction address: 0xd0000000000698e4
      sym1: <1010-66> rev 0x1 at pci 0002:41:01.1 irq 216
      sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking
      sym1: SCSI BUS has been reset.
      scsi2 : sym-2.2.2
      cpu 0x0: Vector: 300 (Data Access) at [c00000002f447a30]
          pc: d0000000000698e4: .scsi_run_queue+0x2c/0x218 [scsi_mod]
          lr: d00000000006a904: .scsi_run_host_queues+0x28/0x5c [scsi_mod]
          sp: c00000002f447cb0
         msr: 9000000000009032
         dar: 1b8
       dsisr: 40000000
        current = 0xc0000000045fecd0
        paca    = 0xc00000000048ee80
          pid   = 1123, comm = scsi_eh_1
      enter ? for help
      [c00000002f447d60] d00000000006a904 .scsi_run_host_queues+0x28/0x5c [scsi_mod]
      [c00000002f447df0] d000000000069054 .scsi_error_handler+0xdb4/0xe44 [scsi_mod]
      [c00000002f447ee0] c00000000007b4e0 .kthread+0x128/0x178
      [c00000002f447f90] c000000000025e84 .kernel_thread+0x4c/0x68
      Signed-off-by: default avatarBrian King <brking@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      309bd271
  12. 26 Jun, 2006 2 commits
  13. 10 Jun, 2006 2 commits
  14. 01 Jun, 2006 1 commit
  15. 15 May, 2006 1 commit
    • Tejun Heo's avatar
      [PATCH] SCSI: implement shost->host_eh_scheduled · ee7863bc
      Tejun Heo authored
      libata needs to invoke EH without scmd.  This patch adds
      shost->host_eh_scheduled to implement such behavior.
      
      Currently the only user of this feature is libata and no general
      interface is defined.  This patch simply adds handling for
      host_eh_scheduled where needed and exports scsi_eh_wakeup() to
      modules.  The rest is upto libata.  This is the result of the
      following discussion.
      
      http://thread.gmane.org/gmane.linux.scsi/23853/focus=9760
      
      
      
      In short, SCSI host is not supposed to know about exceptions unrelated
      to specific device or command.  Such exceptions should be handled by
      transport layer proper.  However, the distinction is not essential to
      ATA and libata is planning to depart from SCSI, so, for the time
      being, libata will be using SCSI EH to handle such exceptions.
      Signed-off-by: default avatarTejun Heo <htejun@gmail.com>
      ee7863bc
  16. 27 Apr, 2006 1 commit
    • James Bottomley's avatar
      [SCSI] Fix DVD burning issues. · f3e93f73
      James Bottomley authored
      
      
      Some pioneer DVDs are apparently returning odd "not ready" status
      codes that the mid-layer doesn't recognise and so passes back to the
      user as errors.
      
      This patch overhauls our not-ready handling and adds transparent retries for:
      
      format in progress
      rebuild in progress
      recalculation in progress
      operation in progress
      Long write in progress
      self test in progress
      
      The Pioneer was actually returning "long write in progress"
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      f3e93f73
  17. 20 Apr, 2006 1 commit
  18. 14 Apr, 2006 1 commit
    • Guennadi Liakhovetski's avatar
      [SCSI] dc395x: dynamically map scatter-gather for PIO · cdb8c2a6
      Guennadi Liakhovetski authored
      
      
      The current dc395x driver uses PIO to transfer up to 4 bytes which do not
      get transferred by DMA (under unclear circumstances). For this the driver
      uses page_address() which is broken on highmem. Apart from this the
      actual calculation of the virtual address is wrong (even without highmem).
      So, e.g., for reading it reads bytes from the driver to a wrong address
      and returns wrong data, I guess, for writing it would just output random
      data to the device.
      
      The proper fix, as suggested by many, is to dynamically map data using
      kmap_atomic(page, KM_BIO_SRC_IRQ) / kunmap_atomic(virt). The reason why it
      has not been done until now, although I've done some preliminary patches
      more than a year ago was that nobody interested in fixing this problem was
      able to reliably reproduce it. Now it changed - with the help from
      Sebastian Frei (CC'ed) I was able to trigger the PIO path. Thus, I was
      also able to test and debug it.
      
      There are 4 cases when PIO is used in dc395x - data-in / -out with and
      without scatter-gather. I was able to reproduce and test only data-in with
      and without SG. So, the data-out path is still untested, but it is also
      somewhat simpler than the data-in. Fredrik Roubert (also CC'ed) also had
      PIO triggering on his system, and in his case it was data-out without SG.
      It would be great if he could test the attached patch on his system, but
      even if he cannot, I would still request to apply the patch and just wait
      if anybody cries...
      
      Implementation: I put 2 new functions in scsi_lib.c and their declarations
      in scsi_cmnd.h. I exported them without _GPL, although, I don't feel
      strongly about that - not many drivers are likely to use them. But there
      is at least one more - I want to use them in tmscsim.c. Whether these are
      the right files for the functions and their declarations - not sure
      either. Actually, they are not scsi-specific, so, might go somewhere
      around other scattergather magic? They are not platform specific either,
      and most SG functions are defined under arch/*/... As these issues were
      discussed previously there were some more routines suggested to manipulate
      scattergather buffers, I think, some of them were needed around
      crypto code... So, might be a common place reasonable, like
      lib/scattergather.c? I am open here.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      cdb8c2a6
  19. 13 Apr, 2006 1 commit
  20. 26 Mar, 2006 1 commit
  21. 19 Mar, 2006 1 commit
  22. 28 Feb, 2006 4 commits
  23. 14 Feb, 2006 1 commit
    • James Bottomley's avatar
      [PATCH] add scsi_execute_in_process_context() API · faead26d
      James Bottomley authored
      
      
      We have several points in the SCSI stack (primarily for our device
      functions) where we need to guarantee process context, but (given the
      place where the last reference was released) we cannot guarantee this.
      
      This API gets around the issue by executing the function directly if
      the caller has process context, but scheduling a workqueue to execute
      in process context if the caller doesn't have it.  Unfortunately, it
      requires memory allocation in interrupt context, but it's better than
      what we have previously.  The true solution will require a bit of
      re-engineering, so isn't appropriate for 2.6.16.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      faead26d
  24. 26 Jan, 2006 1 commit
    • brking@us.ibm.com's avatar
      [SCSI] Prevent scsi_execute_async from guessing cdb length · bb1d1073
      brking@us.ibm.com authored
      
      
      When the scsi_execute_async interface was added it ended up reducing
      the flexibility of userspace to send arbitrary scsi commands through
      sg using SG_IO. The SG_IO interface allows userspace to specify the
      CDB length. This is now ignored in scsi_execute_async and it is
      guessed using the COMMAND_SIZE macro, which is not always correct,
      particularly for vendor specific commands. This patch adds a cmd_len
      parameter to the scsi_execute_async interface to allow the caller
      to specify the length of the CDB.
      Signed-off-by: default avatarBrian King <brking@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      bb1d1073
  25. 14 Jan, 2006 1 commit
  26. 09 Jan, 2006 1 commit
  27. 06 Jan, 2006 3 commits
  28. 16 Dec, 2005 1 commit
  29. 15 Dec, 2005 5 commits
    • Mike Christie's avatar
      [SCSI] seperate max_sectors from max_hw_sectors · defd94b7
      Mike Christie authored
      
      
      - export __blk_put_request and blk_execute_rq_nowait
      needed for async REQ_BLOCK_PC requests
      - seperate max_hw_sectors and max_sectors for block/scsi_ioctl.c and
      SG_IO bio.c helpers per Jens's last comments. Since block/scsi_ioctl.c SG_IO was
      already testing against max_sectors and SCSI-ml was setting max_sectors and
      max_hw_sectors to the same value this does not change any scsi SG_IO behavior. It only
      prepares ll_rw_blk.c, scsi_ioctl.c and bio.c for when SCSI-ml begins to set
      a valid max_hw_sectors for all LLDs. Today if a LLD does not set it
      SCSI-ml sets it to a safe default and some LLDs set it to a artificial low
      value to overcome memory and feedback issues.
      
      Note: Since we now cap max_sectors to BLK_DEF_MAX_SECTORS, which is 1024,
      drivers that used to call blk_queue_max_sectors with a large value of
      max_sectors will now see the fs requests capped to BLK_DEF_MAX_SECTORS.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      defd94b7
    • Mike Christie's avatar
      [SCSI] add kmemcache for scsi_io_context · aa7b5cd7
      Mike Christie authored
      
      
      Add kmemcache of scsi io contexts.
      
      In the future when we finalize on where these functions will live
      we can add a mempool for it and do a bioset for out REQ_BLOCK_PC
      bios. This is needed becuase the dm-multipath handlers will
      want to use the scsi_exectute* functions for failover and we cannot
      have them and the bio device allocating from the same mempool.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      aa7b5cd7
    • Mike Christie's avatar
      [SCSI] complete the whole command when it is REQ_BLOCK_PC · 0d95716d
      Mike Christie authored
      
      
      sd does not allow scsi_io_completion to retry commands for
      SG_IO requests, and it make sense that it should not happen for st
      SG_IO commands too. If for st we hit the bottom of scsi_io_completion
      we will probably screw things up pretty bad. This patch returns to the
      block layer that the whole command completed and relies on the caller to check
      the request errors field. For initialization commands like in sd, this adds
      the previous behavior where scsi_io_completion did not process the error.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      0d95716d
    • Mike Christie's avatar
      [SCSI] add retries field to request for REQ_BLOCK_PC use · 17e01f21
      Mike Christie authored
      
      
      For tape we need to control the retries. This patch adds a retries
      counter on the request for REQ_BLOCK_PC commands originating from
      scsi_execute* to use. REQ_BLOCK_PC commands comming from the block
      layer SG_IO path continue to use the retires set in the ULD init_command.
      (scsi_execute* does not set the gendisk so we do not execute
      the init_command in that path).
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      17e01f21
    • Mike Christie's avatar
      [SCSI] Convert SCSI mid-layer to scsi_execute_async · 6e68af66
      Mike Christie authored
      
      
      Add scsi helpers to create really-large-requests and convert
      scsi-ml to scsi_execute_async().
      
      Per Jens's previous comments, I placed this function in scsi_lib.c.
      I made it follow all the queue's limits - I think I did at least :), so
      I removed the warning on the function header.
      
      I think the scsi_execute_* functions should eventually take a request_queue
      and be placed some place where the dm-multipath hw_handler can use them
      if that failover code is going to stay in the kernel. That conversion
      patch will be sent in another mail though.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      6e68af66