1. 09 10月, 2008 2 次提交
    • F
      block: add gfp_mask argument to blk_rq_map_user and blk_rq_map_user_iov · a3bce90e
      FUJITA Tomonori 提交于
      Currently, blk_rq_map_user and blk_rq_map_user_iov always do
      GFP_KERNEL allocation.
      
      This adds gfp_mask argument to blk_rq_map_user and blk_rq_map_user_iov
      so sg can use it (sg always does GFP_ATOMIC allocation).
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NDouglas Gilbert <dougg@torque.net>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      a3bce90e
    • X
      SG_IO block filter whitelist missing MMC SET READ AHEAD command · 35e396cd
      xiphmont@xiph.org 提交于
      I have another request for the block filter SG_IO command whitelist,
      specifically the MMC streaming command set SET READ AHEAD command.
      The command applies only to MMC CDROM/DVDROM drives with the streaming
      optional feature set.  The command is useful to cdparanoia in that it
      allows explicit cache control side effects that are, on many drives,
      cdparanoia's most efficient way to flush/disable the media cache on
      cdrom drives. I am aware of no reason why it should not be accessible
      from usespace.
      
      Also note that the command is already fully accessible through the
      SCSI-native version of the SG_IO ioctl as well as the traditional SG
      interface.  The command is only being refused on block devices.  That
      means that on a typical stock distro, the command is available through
      /dev/sg* but not /dev/scd* although both are typically available and
      accessible.  Filtering the command is not providing any protection,
      only a confusing inconsistency.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      35e396cd
  2. 27 8月, 2008 2 次提交
    • F
      block: rename blk_scsi_cmd_filter to blk_cmd_filter · 4beab5c6
      FUJITA Tomonori 提交于
      Technically, the cmd_filter would be applied to other protocols though
      it's unlikely to happen. Putting SCSI stuff to request_queue is kinda
      layer violation. So let's rename it.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      4beab5c6
    • F
      block: move cmdfilter from gendisk to request_queue · abf54393
      FUJITA Tomonori 提交于
      cmd_filter works only for the block layer SG_IO with SCSI block
      devices. It breaks scsi/sg.c, bsg, and the block layer SG_IO with SCSI
      character devices (such as st). We hit a kernel crash with them.
      
      The problem is that cmd_filter code accesses to gendisk (having struct
      blk_scsi_cmd_filter) via inode->i_bdev->bd_disk. It works for only
      SCSI block device files. With character device files, inode->i_bdev
      leads you to struct cdev. inode->i_bdev->bd_disk->blk_scsi_cmd_filter
      isn't safe.
      
      SCSI ULDs don't expose gendisk; they keep it private. bsg needs to be
      independent on any protocols. We shouldn't change ULDs to expose their
      gendisk.
      
      This patch moves struct blk_scsi_cmd_filter from gendisk to
      request_queue, a common object, which eveyone can access to.
      
      The user interface doesn't change; users can change the filters via
      /sys/block/. gendisk has a pointer to request_queue so the cmd_filter
      code accesses to struct blk_scsi_cmd_filter.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      abf54393
  3. 30 7月, 2008 1 次提交
    • T
      [SCSI] block: Fix miscalculation of sg_io timeout in CDROM_SEND_PACKET handler. · ad337591
      Tim Wright 提交于
      It seems cdrwtool in the udftools has been unusable on "modern" kernels
      for some time. A Google search reveals many people with the same issue
      but no solution (cdrwtool fails to format the disk). After spending some
      time tracking down the issue, it comes down to the following:
      
      The udftools still use the older CDROM_SEND_PACKET interface to send
      things like FORMAT_UNIT through to the drive. They should really be
      updated, but that's another story. Since most distros are using libata
      now, the cd or dvd burner appears as a SCSI device, and we wind up in
      block/scsi_ioctl.c. Here, the code tries to take the "struct
      cdrom_generic_command" and translate it and stuff it into a "struct
      sg_io_hdr" structure so it can pass it to the modern sg_io() routine
      instead. Unfortunately, there is one error, or rather an omission in the
      translation. The timeout that is passed in in the "struct
      cdrom_generic_command" is in HZ=100 units, and this is modified and
      correctly converted to jiffies by use of clock_t_to_jiffies(). However,
      a little further down, this cgc.timeout value in jiffies is simply
      copied into the sg_io_hdr timeout, which should be in milliseconds.
      Since most modern x86 kernels seems to be getting build with HZ=250, the
      timeout that is passed to sg_io and eventually converted to the
      timeout_per_command member of the scsi_cmnd structure is now four times
      too small. Since cdrwtool tries to set the timeout to one hour for the
      FORMAT_UNIT command, and it takes about 20 minutes to format a 4x CDRW,
      the SCSI error-handler kicks in after the FORMAT_UNIT completes because
      it took longer than the incorrectly-calculated timeout.
      
      [jejb: fix up whitespace]
      Signed-off-by: NTim Wright <timw@splhi.com>
      Cc: Stable Tree <stable@kernel.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      ad337591
  4. 03 7月, 2008 1 次提交
  5. 03 5月, 2008 1 次提交
  6. 29 4月, 2008 1 次提交
  7. 04 3月, 2008 1 次提交
    • F
      block: restore the meaning of rq->data_len to the true data length · 7a85f889
      FUJITA Tomonori 提交于
      The meaning of rq->data_len was changed to the length of an allocated
      buffer from the true data length. It breaks SG_IO friends and
      bsg. This patch restores the meaning of rq->data_len to the true data
      length and adds rq->extra_len to store an extended length (due to
      drain buffer and padding).
      
      This patch also removes the code to update bio in blk_rq_map_user
      introduced by the commit 40b01b9b.
      The commit adjusts bio according to memory alignment
      (queue_dma_alignment). However, memory alignment is NOT padding
      alignment. This adjustment also breaks SG_IO friends and bsg. Padding
      alignment needs to be fixed in a proper way (by a separate patch).
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJens Axboe <axboe@carl.home.kernel.dk>
      7a85f889
  8. 19 2月, 2008 1 次提交
    • T
      block: add request->raw_data_len · 6b00769f
      Tejun Heo 提交于
      With padding and draining moved into it, block layer now may extend
      requests as directed by queue parameters, so now a request has two
      sizes - the original request size and the extended size which matches
      the size of area pointed to by bios and later by sgs.  The latter size
      is what lower layers are primarily interested in when allocating,
      filling up DMA tables and setting up the controller.
      
      Both padding and draining extend the data area to accomodate
      controller characteristics.  As any controller which speaks SCSI can
      handle underflows, feeding larger data area is safe.
      
      So, this patch makes the primary data length field, request->data_len,
      indicate the size of full data area and add a separate length field,
      request->raw_data_len, for the unmodified request size.  The latter is
      used to report to higher layer (userland) and where the original
      request size should be fed to the controller or device.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      6b00769f
  9. 18 12月, 2007 1 次提交
  10. 24 7月, 2007 1 次提交
  11. 22 7月, 2007 1 次提交
  12. 20 7月, 2007 1 次提交
  13. 16 7月, 2007 4 次提交
  14. 18 4月, 2007 1 次提交
    • A
      [SCSI] sg: cap reserved_size values at max_sectors · 44ec9542
      Alan Stern 提交于
      This patch (as857) modifies the SG_GET_RESERVED_SIZE and
      SG_SET_RESERVED_SIZE ioctls in the sg driver, capping the values at
      the device's request_queue's max_sectors value.  This will permit
      cdrecord to obtain a legal value for the maximum transfer length,
      fixing Bugzilla #7026.
      
      The patch also caps the initial reserved_size value.  There's no
      reason to have a reserved buffer larger than max_sectors, since it
      would be impossible to use the extra space.
      
      The corresponding ioctls in the block layer are modified similarly,
      and the initial value for the reserved_size is set as large as
      possible.  This will effectively make it default to max_sectors.
      Note that the actual value is meaningless anyway, since block devices
      don't have a reserved buffer.
      
      Finally, the BLKSECTGET ioctl is added to sg, so that there will be a
      uniform way for users to determine the actual max_sectors value for
      any raw SCSI transport.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NJens Axboe <jens.axboe@oracle.com>
      Acked-by: NDouglas Gilbert <dougg@torque.net>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      44ec9542
  15. 30 1月, 2007 1 次提交
  16. 19 12月, 2006 1 次提交
    • J
      [PATCH] Fixup blk_rq_unmap_user() API · 8e5cfc45
      Jens Axboe 提交于
      The blk_rq_unmap_user() API is not very nice. It expects the caller to
      know that rq->bio has to be reset to the original bio, and it will
      silently do nothing if that is not done. Instead make it explicit that
      we need to pass in the first bio, by expecting a bio argument.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      8e5cfc45
  17. 12 12月, 2006 2 次提交
  18. 01 12月, 2006 1 次提交
  19. 17 11月, 2006 1 次提交
  20. 16 11月, 2006 1 次提交
  21. 14 11月, 2006 1 次提交
  22. 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
  23. 13 4月, 2006 1 次提交
    • C
      [SCSI] unify SCSI_IOCTL_SEND_COMMAND implementations · 21b2f0c8
      Christoph Hellwig 提交于
      We currently have two implementations of this obsolete ioctl, one in
      the block layer and one in the scsi code.  Both of them have drawbacks.
      
      This patch kills the scsi layer version after updating the block version
      with the missing bits:
      
       - argument checking
       - use scatterlist I/O
       - set number of retries based on the submitted command
      
      This is the last user of non-S/G I/O except for the gdth driver, so
      getting this in ASAP and through the scsi tree would be nie to kill
      the non-S/G I/O path.  Jens, what do you think about adding a check
      for non-S/G I/O in the midlayer?
      
      Thanks to  Or Gerlitz for testing this patch.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      21b2f0c8
  24. 08 2月, 2006 1 次提交
  25. 12 1月, 2006 1 次提交
  26. 09 1月, 2006 1 次提交
  27. 06 1月, 2006 1 次提交
  28. 20 12月, 2005 1 次提交
  29. 16 12月, 2005 1 次提交
    • M
      [SCSI] seperate max_sectors from max_hw_sectors · defd94b7
      Mike Christie 提交于
      - 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: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      defd94b7
  30. 04 11月, 2005 1 次提交
  31. 09 10月, 2005 1 次提交
  32. 18 9月, 2005 1 次提交
  33. 10 9月, 2005 1 次提交
    • D
      [SCSI] permit READ DEFECT DATA in block/scsi_ioctl · 942fc2fb
      Douglas Gilbert 提交于
      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: NDouglas Gilbert <dougg@torque.net>
      Acked-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      942fc2fb
  34. 20 6月, 2005 1 次提交