1. 16 10月, 2007 4 次提交
  2. 13 10月, 2007 5 次提交
    • M
      [SCSI] Get rid of scsi_cmnd->done · 6f5391c2
      Matthew Wilcox 提交于
      The ULD ->done callback moves into the scsi_driver.  By moving the call
      to scsi_io_completion() from scsi_blk_pc_done() to scsi_finish_command(),
      we can eliminate the latter entirely.  By returning 'good_bytes' from
      the ->done callback (rather than invoking scsi_io_completion()), we can
      stop exporting scsi_io_completion().
      
      Also move the prototypes from sd.h to sd.c as they're all internal anyway.
      Rename sd_rw_intr to sd_done and rw_intr to sr_done.
      Inspired-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      6f5391c2
    • J
      [SCSI] Fix device not ready printk · 311b581e
      James Bottomley 提交于
      Because scsi_print_sense_hdr prefixes with KERN_INFO, the output from
      scsi_io_completion looks like:
      
      sd 0:0:0:0: [sdb] Device not ready: <6>: Sense Key : 0x2 [current]
      : ASC=0x4 ASCQ=0x3
      
      By using scsi_show_sense_hdr, we can get the much more appealing output:
      
      sd 0:0:0:0: [sdb] Device not ready: Sense Key : 0x2 [current]
      sd 0:0:0:0: [sdb] Device not ready: ASC=0x4 ASCQ=0x3
      Acked-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      311b581e
    • J
      [SCSI] move ULD attachment into the prep function · 7f9a6bc4
      James Bottomley 提交于
      One of the intents of the block prep function was to allow ULDs to use
      it for preprocessing.  The original SCSI model was to have a single prep
      function and add a pointer indirect filter to build the necessary
      commands.  This patch reverses that, does away with the init_command
      field of the scsi_driver structure and makes ULDs attach directly to the
      prep function instead.  The value is really that it allows us to begin
      to separate the ULDs from the SCSI mid layer (as long as they don't use
      any core functions---which is hard at the moment---a ULD doesn't even
      need SCSI to bind).
      Acked-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      7f9a6bc4
    • M
      [SCSI] stale residual returned on write following BUSY retry · 52aeeca9
      Michael Reed 提交于
      A BUSY status returned on a write request results in a stale residual
      being returned when the write ultimately successfully completes.
      
      This can be reproduced as follows:
      
      1) issue immediate mode rewind to scsi tape drive
      2) issue write request
      
      The tape drive returns busy.  The low level driver detects underrun and
      sets the residual into the scsi command.  The low level driver responds
      with (DID_OK << 16) | scsi_status.  scsi_status is 8, hence
      status_byte(result) == 4, i.e., BUSY.
      
      scsi_softirq_done() calls scsi_decide_disposition() which returns
      ADD_TO_MLQUEUE.  scsi_softirq_done() then calls scsi_queue_insert()
      which, on the way to resubmitting the request to the driver, calls
      scsi_init_cmd_errh().
      
      The attached patch modifies scsi_init_cmd_errh() to clear the resid
      field.  This prevents a "stale" residual from being returned when the
      scsi command finally completes without a BUSY status.
      Signed-off-by: NMichael Reed <mdr@sgi.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      52aeeca9
    • M
      [SCSI] fix write buffer length in scsi_req_map_sg() · bd441dea
      Mike Christie 提交于
      sg's may have setup a the buffer with a different length than
      the transfer length so we should be using the bufflen passed
      in as the request's data len.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      bd441dea
  3. 10 10月, 2007 2 次提交
  4. 04 8月, 2007 1 次提交
  5. 24 7月, 2007 1 次提交
  6. 20 7月, 2007 1 次提交
    • P
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt 提交于
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      20c2df83
  7. 15 7月, 2007 1 次提交
    • C
      [SCSI] don't build scsi_dma_{map,unmap} for !HAS_DMA · 7689e82e
      Cornelia Huck 提交于
      With
      
       dma-mapping-prevent-dma-dependent-code-from-linking-on.patch
      
      scsi fails to build on !HAS_DMA architectures:
      
      drivers/built-in.o(.text+0x20af6): In function `scsi_dma_map':
      : undefined reference to `dma_map_sg'
      drivers/built-in.o(.text+0x20b5c): In function `scsi_dma_unmap':
      : undefined reference to `dma_unmap_sg'
      
      I split those functions out into a new file. Builds on s390 and i386.
      
      Move scsi_dma_{map,unmap} into scsi_lib_dma.c which is only build if
      HAS_DMA is set.
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: James Bottomley <James.Bottomley@SteelEye.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      7689e82e
  8. 27 5月, 2007 1 次提交
  9. 09 5月, 2007 1 次提交
  10. 30 4月, 2007 1 次提交
    • J
      [BLOCK] Don't pin lots of memory in mempools · 5972511b
      Jens Axboe 提交于
      Currently we scale the mempool sizes depending on memory installed
      in the machine, except for the bio pool itself which sits at a fixed
      256 entry pre-allocation.
      
      There's really no point in "optimizing" this OOM path, we just need
      enough preallocated to make progress. A single unit is enough, lets
      scale it down to 2 just to be on the safe side.
      
      This patch saves ~150kb of pinned kernel memory on a 32-bit box.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      5972511b
  11. 20 3月, 2007 1 次提交
  12. 12 3月, 2007 1 次提交
  13. 12 2月, 2007 1 次提交
  14. 08 2月, 2007 1 次提交
  15. 14 1月, 2007 1 次提交
  16. 19 12月, 2006 2 次提交
  17. 08 12月, 2006 1 次提交
  18. 26 11月, 2006 1 次提交
    • F
      [SCSI] export scsi-ml functions needed by tgt_scsi_lib and its LLDs · b58d9154
      FUJITA Tomonori 提交于
      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: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b58d9154
  19. 17 11月, 2006 1 次提交
  20. 16 11月, 2006 1 次提交
    • C
      [SCSI] untangle scsi_prep_fn · 3b003157
      Christoph Hellwig 提交于
      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: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      3b003157
  21. 26 10月, 2006 1 次提交
  22. 02 10月, 2006 1 次提交
  23. 01 10月, 2006 1 次提交
    • J
      [PATCH] Split struct request ->flags into two parts · 4aff5e23
      Jens Axboe 提交于
      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: NJens Axboe <axboe@suse.de>
      4aff5e23
  24. 20 8月, 2006 1 次提交
    • A
      [SCSI] limit recursion when flushing shost->starved_list · 04846f25
      Andreas Herrmann 提交于
      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: NAndreas Herrmann <aherrman@de.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      04846f25
  25. 10 7月, 2006 1 次提交
    • C
      [SCSI] hide EH backup data outside the scsi_cmnd · 631c228c
      Christoph Hellwig 提交于
      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: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      631c228c
  26. 03 7月, 2006 1 次提交
  27. 29 6月, 2006 1 次提交
    • B
      [SCSI] scsi: Device scanning oops for offlined devices (resend) · 309bd271
      Brian King 提交于
      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: NBrian King <brking@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      309bd271
  28. 26 6月, 2006 2 次提交
  29. 11 6月, 2006 1 次提交
  30. 10 6月, 2006 1 次提交