1. 23 4月, 2008 1 次提交
    • F
      [SCSI] bsg: add release callback support · 97f46ae4
      FUJITA Tomonori 提交于
      This patch adds release callback support, which is called when a bsg
      device goes away. bsg_register_queue() takes a pointer to a callback
      function. This feature is useful for stuff like sas_host that can't
      use the release callback in struct device.
      
      If a caller doesn't need bsg's release callback, it can call
      bsg_register_queue() with NULL pointer (e.g. scsi devices can use
      release callback in struct device so they don't need bsg's callback).
      
      With this patch, bsg uses kref for refcounts on bsg devices instead of
      get/put_device in fops->open/release. bsg calls put_device and the
      caller's release callback (if it was registered) in kref_put's
      release.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      97f46ae4
  2. 21 4月, 2008 4 次提交
    • A
      block: fix blk_register_queue() return value · fb199746
      Akinobu Mita 提交于
      blk_register_queue() returns -ENXIO when queue->request_fn is NULL.  But there
      are some block drivers that call blk_register_queue() via add_disk() with
      queue->request_fn == NULL.  (For example, brd, loop)
      
      Although no one checks return value of blk_register_queue(), this patch makes
      it return 0 instead of -ENXIO when queue->request_fn is NULL,
      
      Also this patch adds warning when blk_register_queue() and
      blk_unregister_queue() are called with queue == NULL rather than ignore
      invalid usage silently.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      fb199746
    • N
      Kconfig: clean up block/Kconfig help descriptions · ee86418d
      Nick Andrew 提交于
      Modify the help descriptions of block/Kconfig for clarity, accuracy and
      consistency.
      
      Refactor the BLOCK description a bit.  The wording "This permits ...  to be
      removed" isn't quite right; the block layer is removed when the option is
      disabled, whereas most descriptions talk about what happens when the option is
      enabled.  Reformat the list of what is affected by disabling the block layer.
      
      Add more examples of large block devices to LBD and strive for technical
      accuracy; block devices of size _exactly_ 2TB require CONFIG_LBD, not only
      "bigger than 2TB".  Also try to say (perhaps not very clearly) that the config
      option is only needed when you want to have individual block devices of size
      >= 2TB, for example if you had 3 x 1TB disks in your computer you'd have a
      total storage size of 3TB but you wouldn't need the option unless you want to
      aggregate those disks into a RAID or LVM.
      
      Improve terminology and grammar on BLK_DEV_IO_TRACE.
      
      I also added the boilerplate "If unsure, say N" to most options.
      
      Precisely say "2TB and larger" for LSF.
      
      Indent the help text for BLK_DEV_BSG by 2 spaces in accordance with the
      standard.
      Signed-off-by: NNick Andrew <nick@nick-andrew.net>
      Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      ee86418d
    • F
      block: move the padding adjustment to blk_rq_map_sg · f18573ab
      FUJITA Tomonori 提交于
      blk_rq_map_user adjusts bi_size of the last bio. It breaks the rule
      that req->data_len (the true data length) is equal to sum(bio). It
      broke the scsi command completion code.
      
      commit e97a294e was introduced to fix
      the above issue. However, the partial completion code doesn't work
      with it. The commit is also a layer violation (scsi mid-layer should
      not know about the block layer's padding).
      
      This patch moves the padding adjustment to blk_rq_map_sg (suggested by
      James). The padding works like the drain buffer. This patch breaks the
      rule that req->data_len is equal to sum(sg), however, the drain buffer
      already broke it. So this patch just restores the rule that
      req->data_len is equal to sub(bio) without breaking anything new.
      
      Now when a low level driver needs padding, blk_rq_map_user and
      blk_rq_map_user_iov guarantee there's enough room for padding.
      blk_rq_map_sg can safely extend the last entry of a scatter list.
      
      blk_rq_map_sg must extend the last entry of a scatter list only for a
      request that got through bio_copy_user_iov. This patches introduces
      new REQ_COPY_USER flag.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Tejun Heo <htejun@gmail.com>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      f18573ab
    • F
      block: add bio_copy_user_iov support to blk_rq_map_user_iov · afdc1a78
      FUJITA Tomonori 提交于
      With this patch, blk_rq_map_user_iov uses bio_copy_user_iov when a low
      level driver needs padding or a buffer in sg_iovec isn't aligned. That
      is, it uses temporary kernel buffers instead of mapping user pages
      directly.
      
      When a LLD needs padding, later blk_rq_map_sg needs to extend the last
      entry of a scatter list. bio_copy_user_iov guarantees that there is
      enough space for padding by using temporary kernel buffers instead of
      user pages.
      
      blk_rq_map_user_iov needs buffers in sg_iovec to be aligned. The
      comment in blk_rq_map_user_iov indicates that drivers/scsi/sg.c also
      needs buffers in sg_iovec to be aligned. Actually, drivers/scsi/sg.c
      works with unaligned buffers in sg_iovec (it always uses temporary
      kernel buffers).
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Tejun Heo <htejun@gmail.com>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      afdc1a78
  3. 20 4月, 2008 1 次提交
  4. 19 4月, 2008 5 次提交
  5. 18 4月, 2008 1 次提交
    • B
      ide: remove broken/dangerous HDIO_[UNREGISTER,SCAN]_HWIF ioctls (take 3) · 93de00fd
      Bartlomiej Zolnierkiewicz 提交于
      hdparm explicitely marks HDIO_[UNREGISTER,SCAN]_HWIF ioctls as DANGEROUS
      and given the number of bugs we can assume that there are no real users:
      
      * DMA has no chance of working because DMA resources are released by
        ide_unregister() and they are never allocated again.
      
      * Since ide_init_hwif_ports() is used for ->io_ports[] setup the ioctls
        don't work for almost all hosts with "non-standard" (== non ISA-like)
        layout of IDE taskfile registers (there is a lot of such host drivers).
      
      * ide_port_init_devices() is not called when probing IDE devices so:
        - drive->autotune is never set and IDE host/devices are not programmed
          for the correct PIO/DMA transfer modes (=> possible data corruption)
        - host specific I/O 32-bit and IRQ unmasking settings are not applied
          (=> possible data corruption)
        - host specific ->port_init_devs method is not called (=> no luck with
          ht6560b, qd65xx and opti621 host drivers)
      
      * ->rw_disk method is not preserved (=> no HPT3xxN chipsets support).
      
      * ->serialized flag is not preserved (=> possible data corruption when
         using icside, aec62xx (ATP850UF chipset), cmd640, cs5530, hpt366
         (HPT3xxN chipsets), rz1000, sc1200, dtc2278 and ht6560b host drivers).
      
      * ->ack_intr method is not preserved (=> needed by ide-cris, buddha,
        gayle and macide host drivers).
      
      * ->sata_scr[] and sata_misc[] is cleared by ide_unregister() and it
        isn't initialized again (SiI3112 support needs them).
      
      * To issue an ioctl() there need to be at least one IDE device present
        in the system.
      
      * ->cable_detect method is not preserved + it is not called when probing
        IDE devices so cable detection is broken (however since DMA support is
        also broken it doesn't really matter ;-).
      
      * Some objects which may have already been freed in ide_unregister()
        are restored by ide_hwif_restore() (i.e. ->hwgroup).
      
      * ide_register_hw() may unregister unrelated IDE ports if free ide_hwifs[]
        slot cannot be found.
      
      * When IDE host drivers are modular unregistered port may be re-used by
        different host driver that owned it first causing subtle bugs.
      
      Since we now have a proper warm-plug support remove these ioctls,
      then remove no longer needed:
      - ide_register_hw() and ide_hwif_restore() functions
      - 'init_default' and 'restore' arguments of ide_unregister()
      - zeroeing of hwif->{dma,extra}_* fields in ide_unregister()
      
      As an added bonus IDE core code size shrinks by ~3kB (x86-32).
      
      v2:
      * fix ide_unregister() arguments in cleanup_module() (Andrew Morton).
      
      v3:
      * fix ide_unregister() arguments in palm_bk3710.c.
      Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      93de00fd
  6. 15 4月, 2008 1 次提交
  7. 10 4月, 2008 1 次提交
    • F
      cfq-iosched: do not leak ioc_data across iosched switches · 4faa3c81
      Fabio Checconi 提交于
      When switching scheduler from cfq, cfq_exit_queue() does not clear
      ioc->ioc_data, leaving a dangling pointer that can deceive the following
      lookups when the iosched is switched back to cfq.  The pattern that can
      trigger that is the following:
      
          - elevator switch from cfq to something else;
          - module unloading, with elv_unregister() that calls cfq_free_io_context()
            on ioc freeing the cic (via the .trim op);
          - module gets reloaded and the elevator switches back to cfq;
          - reallocation of a cic at the same address as before (with a valid key).
      
      To fix it just assign NULL to ioc_data in __cfq_exit_single_io_context(),
      that is called from the regular exit path and from the elevator switching
      code.  The only path that frees a cic and is not covered is the error handling
      one, but cic's freed in this way are never cached in ioc_data.
      Signed-off-by: NFabio Checconi <fabio@gandalf.sssup.it>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      4faa3c81
  8. 02 4月, 2008 2 次提交
    • F
      cfq-iosched: fix rcu freeing of cfq io contexts · 34e6bbf2
      Fabio Checconi 提交于
      SLAB_DESTROY_BY_RCU is not a direct substitute for normal call_rcu()
      freeing, since it'll page freeing but NOT object freeing. So change
      cfq to do the freeing on its own.
      Signed-off-by: NFabio Checconi <fabio@gandalf.sssup.it>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      34e6bbf2
    • A
      Fix bounce setting for 64-bit · 00d61e3e
      Andrea Arcangeli 提交于
      Looking a bit closer into this regression the reason this can't be
      right is that dma_addr common default is BLK_BOUNCE_HIGH and most
      machines have less than 4G. So if you do:
      
          if (b_pfn <= (min_t(u64, 0xffffffff, BLK_BOUNCE_HIGH) >> PAGE_SHIFT))
      	dma = 1
      
      that will translate to:
      
           if (BLK_BOUNCE_HIGH <= BLK_BOUNCE_HIGH)
           	dma = 1
      
      So for 99% of hardware this will trigger unnecessary GFP_DMA
      allocations and isa pooling operations.
      
      Also note how the 32bit code still does b_pfn < blk_max_low_pfn.
      
      I guess this is what you were looking after. I didn't verify but as
      far as I can tell, this will stop the regression with isa dma
      operations at boot for 99% of blkdev/memory combinations out there and
      I guess this fixes the setups with >4G of ram and 32bit pci cards as
      well (this also retains symmetry with the 32bit code).
      Signed-off-by: NAndrea Arcangeli <andrea@qumranet.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      00d61e3e
  9. 13 3月, 2008 1 次提交
  10. 04 3月, 2008 12 次提交
  11. 19 2月, 2008 10 次提交
  12. 08 2月, 2008 1 次提交