1. 02 10月, 2009 1 次提交
  2. 11 5月, 2009 1 次提交
    • T
      block: convert to pos and nr_sectors accessors · 83096ebf
      Tejun Heo 提交于
      With recent cleanups, there is no place where low level driver
      directly manipulates request fields.  This means that the 'hard'
      request fields always equal the !hard fields.  Convert all
      rq->sectors, nr_sectors and current_nr_sectors references to
      accessors.
      
      While at it, drop superflous blk_rq_pos() < 0 test in swim.c.
      
      [ Impact: use pos and nr_sectors accessors ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Tested-by: NGrant Likely <grant.likely@secretlab.ca>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Tested-by: NAdrian McMenamin <adrian@mcmen.demon.co.uk>
      Acked-by: NAdrian McMenamin <adrian@mcmen.demon.co.uk>
      Acked-by: NMike Miller <mike.miller@hp.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Cc: Borislav Petkov <petkovbb@googlemail.com>
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: Eric Moore <Eric.Moore@lsi.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Pete Zaitcev <zaitcev@redhat.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Paul Clements <paul.clements@steeleye.com>
      Cc: Tim Waugh <tim@cyberelk.net>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Alex Dubov <oakad@yahoo.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Dario Ballabio <ballabio_dario@emc.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: unsik Kim <donari75@gmail.com>
      Cc: Laurent Vivier <Laurent@lvivier.info>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      83096ebf
  3. 13 3月, 2009 1 次提交
  4. 09 10月, 2008 1 次提交
  5. 27 7月, 2008 2 次提交
    • M
      [SCSI] Support devices with protection information · 7027ad72
      Martin K. Petersen 提交于
      Implement support for DMA of protection information for devices that
      are data integrity capable.
      
       - Add support for mapping an extra scatter-gather list containing
         the protection information.
      
       - Allocate protection scsi_data_buffer if host is DIX (integrity DMA)
         capable.
      
       - Accessor function for checking whether a device has protection
         enabled.
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      7027ad72
    • M
      [SCSI] Command protection operation · db007fc5
      Martin K. Petersen 提交于
      Controllers that support DMA of protection information must be told
      explicitly how to handle the I/O.  The controller has no knowledge of
      the protection capabilities of the target device so this information
      must be passed in the scsi_cmnd.
      
       - The protection operation tells the HBA whether to generate, strip or
         verify protection information.
      
       - The protection type tells the HBA which layout the target is
         formatted with.  This is necessary because the controller must be
         able to correctly interpret the included protection information in
         order to verify it.
      
       - When a scsi_cmnd is reused for error handling the protection
         operation must be cleared and saved while error handling is in
         progress.
      
       - prot_op and prot_type are placed in an existing hole in scsi_cmnd
         and don't cause the structure to grow.
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      db007fc5
  6. 12 7月, 2008 1 次提交
  7. 03 5月, 2008 1 次提交
  8. 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
  9. 08 4月, 2008 2 次提交
  10. 31 1月, 2008 3 次提交
    • B
      [SCSI] bidirectional command support · 6f9a35e2
      Boaz Harrosh 提交于
      At the block level bidi request uses req->next_rq pointer for a second
      bidi_read request.
      At Scsi-midlayer a second scsi_data_buffer structure is used for the
      bidi_read part. This bidi scsi_data_buffer is put on
      request->next_rq->special. Struct scsi_cmnd is not changed.
      
      - Define scsi_bidi_cmnd() to return true if it is a bidi request and a
        second sgtable was allocated.
      
      - Define scsi_in()/scsi_out() to return the in or out scsi_data_buffer
        from this command This API is to isolate users from the mechanics of
        bidi.
      
      - Define scsi_end_bidi_request() to do what scsi_end_request() does but
        for a bidi request. This is necessary because bidi commands are a bit
        tricky here. (See comments in body)
      
      - scsi_release_buffers() will also release the bidi_read scsi_data_buffer
      
      - scsi_io_completion() on bidi commands will now call
        scsi_end_bidi_request() and return.
      
      - The previous work done in scsi_init_io() is now done in a new
        scsi_init_sgtable() (which is 99% identical to old scsi_init_io())
        The new scsi_init_io() will call the above twice if needed also for
        the bidi_read command. Only at this point is a command bidi.
      
      - In scsi_error.c at scsi_eh_prep/restore_cmnd() make sure bidi-lld is not
        confused by a get-sense command that looks like bidi. This is done
        by puting NULL at request->next_rq, and restoring.
      
      [jejb: update to sg_table and resolve conflicts
      also update to blk-end-request and resolve conflicts]
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      6f9a35e2
    • B
      [SCSI] implement scsi_data_buffer · 30b0c37b
      Boaz Harrosh 提交于
      In preparation for bidi we abstract all IO members of scsi_cmnd,
      that will need to duplicate, into a substructure.
      
      - Group all IO members of scsi_cmnd into a scsi_data_buffer
        structure.
      - Adjust accessors to new members.
      - scsi_{alloc,free}_sgtable receive a scsi_data_buffer instead of
        scsi_cmnd. And work on it.
      - Adjust scsi_init_io() and  scsi_release_buffers() for above
        change.
      - Fix other parts of scsi_lib/scsi.c to members migration. Use
        accessors where appropriate.
      
      - fix Documentation about scsi_cmnd in scsi_host.h
      
      - scsi_error.c
        * Changed needed members of struct scsi_eh_save.
        * Careful considerations in scsi_eh_prep/restore_cmnd.
      
      - sd.c and sr.c
        * sd and sr would adjust IO size to align on device's block
          size so code needs to change once we move to scsi_data_buff
          implementation.
        * Convert code to use scsi_for_each_sg
        * Use data accessors where appropriate.
      
      - tgt: convert libsrp to use scsi_data_buffer
      
      - isd200: This driver still bangs on scsi_cmnd IO members,
        so need changing
      
      [jejb: rebased on top of sg_table patches fixed up conflicts
      and used the synergy to eliminate use_sg and sg_count]
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      30b0c37b
    • B
      [SCSI] tgt: use scsi_init_io instead of scsi_alloc_sgtable · bb52d82f
      Boaz Harrosh 提交于
      If we export scsi_init_io()/scsi_release_buffers() instead of
      scsi_{alloc,free}_sgtable() from scsi_lib than tgt code is much more
      insulated from scsi_lib changes. As a bonus it will also gain bidi
      capability when it comes.
      
      [jejb: rebase on to sg_table and fix up rejections]
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      Acked-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      bb52d82f
  11. 28 1月, 2008 1 次提交
  12. 24 1月, 2008 1 次提交
  13. 07 1月, 2008 1 次提交
    • L
      Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done"" · 7b3d9545
      Linus Torvalds 提交于
      This reverts commit ac40532e, which gets
      us back the original cleanup of 6f5391c2.
      
      It turns out that the bug that was triggered by that commit was
      apparently not actually triggered by that commit at all, and just the
      testing conditions had changed enough to make it appear to be due to it.
      
      The real problem seems to have been found by Peter Osterlund:
      
        "pktcdvd sets it [block device size] when opening the /dev/pktcdvd
         device, but when the drive is later opened as /dev/scd0, there is
         nothing that sets it back.  (Btw, 40944 is possible if the disk is a
         CDRW that was formatted with "cdrwtool -m 10236".)
      
         The problem is that pktcdvd opens the cd device in non-blocking mode
         when pktsetup is run, and doesn't close it again until pktsetup -d is
         run.  The effect is that if you meanwhile open the cd device,
         blkdev.c:do_open() doesn't call bd_set_size() because
         bdev->bd_openers is non-zero."
      
      In particular, to repeat the bug (regardless of whether commit
      6f5391c2 is applied or not):
      
        " 1. Start with an empty drive.
          2. pktsetup 0 /dev/scd0
          3. Insert a CD containing an isofs filesystem.
          4. mount /dev/pktcdvd/0 /mnt/tmp
          5. umount /mnt/tmp
          6. Press the eject button.
          7. Insert a DVD containing a non-writable filesystem.
          8. mount /dev/scd0 /mnt/tmp
          9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
          10. If the DVD contains data beyond the physical size of a CD, you
              get I/O errors in the terminal, and dmesg reports lots of
              "attempt to access beyond end of device" errors."
      
      which in turn is because the nested open after the media change won't
      cause the size to be set properly (because the original open still holds
      the block device, and we only do the bd_set_size() when we don't have
      other people holding the device open).
      
      The proper fix for that is probably to just do something like
      
      	bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
      
      in fs/block_dev.c:do_open() even for the cases where we're not the
      original opener (but *not* call bd_set_size(), since that will also
      change the block size of the device).
      
      Cc: Peter Osterlund <petero2@telia.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b3d9545
  14. 03 1月, 2008 1 次提交
  15. 16 10月, 2007 4 次提交
  16. 13 10月, 2007 2 次提交
  17. 27 5月, 2007 1 次提交
  18. 12 3月, 2007 1 次提交
    • M
      [SCSI] tgt: rm bio hacks in scsi tgt · 181011e0
      Mike Christie 提交于
      scsi tgt breaks up a command into multple scatterlists
      if we cannot fit all the data in one. This was because
      the block rq helpers did not support large requests and
      because we can get a command of any old size so it is
      hard to preallocate pages for scatterlist large enough
      (we cannot really preallocate pages with the bio map
      user path). In 2.6.20, we added large request support to
      the block layer helper, blk_rq_map_user. And at LSF,
      we talked about increasing SCSI_MAX_PHYS_SEGMENTS for
      scsi tgt if we want to support really really :) large
      (greater than 256 * PAGE_SIZE in the worst mapping case)
      requests.
      
      The only target currently implemented does not even support
      the multiple scatterlists stuff and only supports smaller
      requests, so this patch just coverts scsi tgt to use
      blk_rq_map_user.
      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>
      181011e0
  19. 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
  20. 07 8月, 2006 1 次提交
  21. 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
  22. 26 6月, 2006 1 次提交
    • L
      [SCSI] sd/scsi_lib simplify sd_rw_intr and scsi_io_completion · 03aba2f7
      Luben Tuikov 提交于
      This patch simplifies "good_bytes" computation in sd_rw_intr().
      sd: "good_bytes" computation is always done in terms of the resolution
      of the device's medium, since after that it is the number of good bytes
      we pass around and other layers/contexts (as opposed ot sd) can translate
      that to their own resolution (block layer:512).  It also makes
      scsi_io_completion() processing more straightforward, eliminating the
      3rd argument to the function.
      
      It also fixes a couple of bugs like not checking return value,
      using "break" instead of "return;", etc.
      
      I've been running with this patch for some time now on a
      test (do-it-all) system.
      Signed-off-by: NLuben Tuikov <ltuikov@yahoo.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      03aba2f7
  23. 11 6月, 2006 1 次提交
  24. 15 5月, 2006 1 次提交
  25. 15 4月, 2006 1 次提交
    • G
      [SCSI] dc395x: dynamically map scatter-gather for PIO · cdb8c2a6
      Guennadi Liakhovetski 提交于
      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: NJames Bottomley <James.Bottomley@SteelEye.com>
      cdb8c2a6
  26. 28 2月, 2006 1 次提交
  27. 15 1月, 2006 1 次提交
  28. 16 12月, 2005 1 次提交
  29. 14 12月, 2005 1 次提交
  30. 31 10月, 2005 1 次提交
    • T
      [PATCH] fix missing includes · 4e57b681
      Tim Schmielau 提交于
      I recently picked up my older work to remove unnecessary #includes of
      sched.h, starting from a patch by Dave Jones to not include sched.h
      from module.h. This reduces the number of indirect includes of sched.h
      by ~300. Another ~400 pointless direct includes can be removed after
      this disentangling (patch to follow later).
      However, quite a few indirect includes need to be fixed up for this.
      
      In order to feed the patches through -mm with as little disturbance as
      possible, I've split out the fixes I accumulated up to now (complete for
      i386 and x86_64, more archs to follow later) and post them before the real
      patch.  This way this large part of the patch is kept simple with only
      adding #includes, and all hunks are independent of each other.  So if any
      hunk rejects or gets in the way of other patches, just drop it.  My scripts
      will pick it up again in the next round.
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4e57b681
  31. 28 10月, 2005 1 次提交
  32. 08 8月, 2005 1 次提交
    • J
      [SCSI] add global timeout to the scsi mid-layer · b21a4138
      James Bottomley 提交于
      There are certain rogue devices (and the aic7xxx driver) that return
      BUSY or QUEUE_FULL forever.  This code will apply a global timeout (of
      the total number of retries times the per command timer) to a given
      command.  If it is exceeded, the command is completed regardless of its
      state.
      
      The patch also removes the unused field in the command: timeout and
      timeout_total.
      
      This solves the problem of detecting an endless loop in the mid-layer
      because of BUSY/QUEUE_FULL bouncing, but will not recover the device.
      In the aic7xxx case, the driver can be recovered by sending a bus reset,
      so possibly this should be tied into the error handler?
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b21a4138