1. 30 10月, 2011 2 次提交
  2. 03 8月, 2011 1 次提交
  3. 24 7月, 2011 1 次提交
    • S
      [S390] dasd: add enhanced DASD statistics interface · 4fa52aa7
      Stefan Weinhuber 提交于
      This patch extends the DASD statistics to allow for a more detailed
      analysis of DASD I/O operations. In particular we want the statistics
      to provide answers to the following questions:
      - How many requests used a PAV alias?
      - How many requests used High Performance FICON?
      - How do read request perform versus write requests?
      
      The existing DASD statistics interface has several shortcomings
      - The interface for global data is a formatted text table in procfs
        (/proc/dasd/statistics). The layout is meant for human readers and
        is not to easy to parse. If values get to large for the table
        layout, they get scaled down.
      - The statistics which are collected per block device can be
        accessed via an ioctl interface, which can only be extended by
        defining a new ioctl.
      - There is no statistics interface for individual PAV base and alias
        devices.
      
      To overcome theses shortcomings we create a new DASD statistics
      interface in debugfs. This interface will contain one entry for global
      data, one per DASD block device, and one per DASD base and alias
      device. Each file contains the statistic data in easy to parse
      name/value and name/array pairs. The existing interfaces will remain
      functional, but they will not be extended.
      Signed-off-by: NStefan Weinhuber <wein@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      4fa52aa7
  4. 10 5月, 2011 1 次提交
  5. 20 4月, 2011 1 次提交
    • S
      [S390] dasd: fix race between open and offline · 65f8da47
      Stefan Weinhuber 提交于
      The dasd_open function uses the private_data pointer of the gendisk to
      find the dasd_block structure that matches the gendisk. When a DASD
      device is set offline, we set the private_data pointer of the gendisk
      to NULL and later remove the dasd_block structure, but there is still
      a small race window, in which dasd_open could first read a pointer
      from the private_data field and then try to use it, after the structure
      has already been freed.
      To close this race window, we will store a pointer to the dasd_devmap
      structure of the base device in the private_data field. The devmap
      entries are not deleted, and we already have proper locking and
      reference counting in place, so that we can safely get from a devmap
      pointer to the dasd_device and dasd_block structures of the device.
      Signed-off-by: NStefan Weinhuber <wein@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      65f8da47
  6. 10 3月, 2011 1 次提交
  7. 05 1月, 2011 7 次提交
  8. 25 10月, 2010 2 次提交
  9. 26 9月, 2010 1 次提交
    • A
      s390/block: kill the big kernel lock · cfdb00a7
      Arnd Bergmann 提交于
      The dasd and dcssblk drivers gained the big
      kernel lock in the recent pushdown from the
      block layer, but they don't really need it,
      so remove the calls without a replacement.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux-s390@vger.kernel.org
      cfdb00a7
  10. 10 9月, 2010 1 次提交
    • T
      block: deprecate barrier and replace blk_queue_ordered() with blk_queue_flush() · 4913efe4
      Tejun Heo 提交于
      Barrier is deemed too heavy and will soon be replaced by FLUSH/FUA
      requests.  Deprecate barrier.  All REQ_HARDBARRIERs are failed with
      -EOPNOTSUPP and blk_queue_ordered() is replaced with simpler
      blk_queue_flush().
      
      blk_queue_flush() takes combinations of REQ_FLUSH and FUA.  If a
      device has write cache and can flush it, it should set REQ_FLUSH.  If
      the device can handle FUA writes, it should also set REQ_FUA.
      
      All blk_queue_ordered() users are converted.
      
      * ORDERED_DRAIN is mapped to 0 which is the default value.
      * ORDERED_DRAIN_FLUSH is mapped to REQ_FLUSH.
      * ORDERED_DRAIN_FLUSH_FUA is mapped to REQ_FLUSH | REQ_FUA.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NBoaz Harrosh <bharrosh@panasas.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Alasdair G Kergon <agk@redhat.com>
      Cc: Pierre Ossman <drzeus@drzeus.cx>
      Cc: Stefan Weinhuber <wein@de.ibm.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      4913efe4
  11. 13 8月, 2010 1 次提交
  12. 08 8月, 2010 2 次提交
  13. 27 5月, 2010 1 次提交
  14. 17 5月, 2010 1 次提交
  15. 12 5月, 2010 1 次提交
    • S
      [S390] dasd: fix race between tasklet and dasd_sleep_on · 1c1e093c
      Stefan Weinhuber 提交于
      The various dasd_sleep_on functions use a global wait queue when
      waiting for a cqr. The wait condition checks the status and devlist
      fields of the cqr to determine if it is safe to continue. This
      evaluation may return true, although the tasklet has not finished
      processing of the cqr and the callback function has not been called
      yet. When the callback is finally called, the data in the cqr may
      already be invalid. The sleep_on wait condition needs a safe way to
      determine if the tasklet has finished processing. Use the
      callback_data field of the cqr to store a token, which is set by
      the callback function itself.
      
      Cc: <stable@kernel.org>
      Signed-off-by: NStefan Weinhuber <wein@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      1c1e093c
  16. 22 4月, 2010 1 次提交
  17. 08 3月, 2010 1 次提交
  18. 27 2月, 2010 3 次提交
  19. 26 2月, 2010 2 次提交
  20. 27 1月, 2010 1 次提交
  21. 07 12月, 2009 4 次提交
  22. 14 10月, 2009 1 次提交
  23. 06 10月, 2009 1 次提交
    • S
      [S390] dasd: fix race condition in resume code · 6fca97a9
      Stefan Haberland 提交于
      There is a race while re-reading the device characteristics. After
      cleaning the memory area a cqr is build which reads the device
      characteristics. This may take a rather long time and the device
      characteristics structure is zero during this. Now it could be
      possible that the block tasklet starts working and a new cqr will be
      build. The build_cp command refers to the device characteristics
      structure and this may lead into a divide by zero exception.
      Fix this by re-reading the device characteristics into a temporary
      structur and copy the data to the original structure. Also take the
      ccwdev_lock.
      Signed-off-by: NStefan Haberland <stefan.haberland@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      6fca97a9
  24. 22 9月, 2009 1 次提交
  25. 11 9月, 2009 1 次提交