Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 16 8月, 2008 2 次提交
  3. 27 7月, 2008 8 次提交
  5. 25 7月, 2008 2 次提交
  7. 12 7月, 2008 1 次提交
  9. 28 5月, 2008 1 次提交
  11. 02 5月, 2008 1 次提交
    • B
      [SCSI] Let scsi_cmnd->cmnd use request->cmd buffer · 64a87b24
      由 Boaz Harrosh 提交于 
       - struct scsi_cmnd had a 16 bytes command buffer of its own.
   This is an unnecessary duplication and copy of request's
   cmd. It is probably left overs from the time that scsi_cmnd
   could function without a request attached. So clean that up.

 - Once above is done, few places, apart from scsi-ml, needed
   adjustments due to changing the data type of scsi_cmnd->cmnd.

 - Lots of drivers still use MAX_COMMAND_SIZE. So I have left
   that #define but equate it to BLK_MAX_CDB. The way I see it
   and is reflected in the patch below is.
   MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB
                      as per the SCSI standard and is not related
                      to the implementation.
   BLK_MAX_CDB.     - The allocated space at the request level

 - I have audit all ISA drivers and made sure none use ->cmnd in a DMA
   Operation. Same audit was done by Andi Kleen.

(*)fixed-length here means commands that their size can be determined
   by their opcode and the CDB does not carry a length specifier, (unlike
   the VARIABLE_LENGTH_CMD(0x7f) command). This is actually not exactly
   true and the SCSI standard also defines extended commands and
   vendor specific commands that can be bigger than 16 bytes. The kernel
   will support these using the same infrastructure used for VARLEN CDB's.
   So in effect MAX_COMMAND_SIZE means the maximum size command
   scsi-ml supports without specifying a cmd_len by ULD's
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      64a87b24
  13. 30 4月, 2008 1 次提交
  15. 20 4月, 2008 1 次提交
  17. 04 3月, 2008 2 次提交
  19. 07 2月, 2008 1 次提交
  21. 31 1月, 2008 1 次提交
    • J
      [SCSI] remove use_sg_chaining · d3f46f39
      由 James Bottomley 提交于 
      With the sg table code, every SCSI driver is now either chain capable
or broken (or has sg_tablesize set so chaining is never activated), so
there's no need to have a check in the host template.

Also tidy up the code by moving the scatterlist size defines into the
SCSI includes and permit the last entry of the scatterlist pools not
to be a power of two.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      d3f46f39
  23. 12 1月, 2008 3 次提交
  25. 04 11月, 2007 1 次提交
    • R
      [SCSI] ibmvscsi: Prevent IO during partner login · 3c887e8a
      由 Robert Jennings 提交于 
      By setting the request_limit in send_srp_login to 1 we allowed login
requests to be sent to the server adapter.  If this was not an initial
login, but was a login after a disconnect with the server, other I/O
requests could attempt to be processed before the login occured.  These
I/O requests would fail, sometimes resulting in filesystems getting
marked read-only.

To address this we can set the request_limit to 0 while doing the login
and add an exception where login requests, along with task management
events, are always passed to the server.

There is a case where the request_limit had already reached 0 would result
in all events being sent rather than returning SCSI_MLQUEUE_HOST_BUSY; this
has also been fixed by this patch.
Signed-off-by: NRobert Jennings <rcj@linux.vnet.ibm.com>
Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      3c887e8a
  27. 16 10月, 2007 1 次提交
  29. 13 10月, 2007 6 次提交
  31. 31 7月, 2007 2 次提交
  33. 15 7月, 2007 1 次提交
  35. 26 6月, 2007 1 次提交
  37. 18 6月, 2007 4 次提交