1. 10 3月, 2011 10 次提交
    • T
      ub: Convert to bdops->check_events() · aaa7c015
      Tejun Heo 提交于
      Convert from ->media_changed() to ->check_events().
      
      ub buffers media changed state and clears it on revalidation.  It will
      behave correctly with kernel event polling.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Pete Zaitcev <zaitcev@redhat.com>
      aaa7c015
    • T
      swim[3]: Convert to bdops->check_events() · 4bbde777
      Tejun Heo 提交于
      Convert from ->media_changed() to ->check_events().
      
      Both swim and swim3 buffer media changed state and clear it on
      revalidation.  They will behave correctly with kernel event polling.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Laurent Vivier <laurent@lvivier.info>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      4bbde777
    • T
      dac960: Convert to bdops->check_events() · 507daea2
      Tejun Heo 提交于
      Convert from ->media_changed() to ->check_events().
      
      DAC960 media change notification seems to be one way (once set, never
      cleared) and will generate spurious events when polled once the
      condition triggers.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      507daea2
    • T
      paride: Convert to bdops->check_events() · b1b56b93
      Tejun Heo 提交于
      Convert paride drivers from ->media_changed() to ->check_events().
      
      pcd and pd buffer and clear events after reporting; however, pf
      unconditionally reports MEDIA_CHANGE and will generate spurious events
      when polled.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Tim Waugh <tim@cyberelk.net>
      b1b56b93
    • T
      gdrom,viocd: Convert to bdops->check_events() · 1c27030b
      Tejun Heo 提交于
      Convert gdrom and viocd from ->media_changed() to ->check_events().
      
      It's unclear how the conditions are cleared and it's possible that it
      may generate spurious events when polled.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      1c27030b
    • T
      floppy,{ami|ata}flop: Convert to bdops->check_events() · 1a8a74f0
      Tejun Heo 提交于
      Convert the floppy drivers from ->media_changed() to ->check_events().
      Both floppy and ataflop buffer media changed state bit and clear them
      on revalidation and will behave correctly with kernel event polling.
      
      I can't tell how amiflop clears its event and it's possible that it
      may generate spurious events when polled.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      1a8a74f0
    • T
      ide: Convert to bdops->check_events() · 5b03a1b1
      Tejun Heo 提交于
      Convert ->media_changed() to the new ->check_events() method.  The
      conversion is mostly mechanical.  The only notable change is that
      cdrom now doesn't generate any event if @slot_nr isn't CDSL_CURRENT.
      It used to return -EINVAL which would be treated as media changed.  As
      media changer isn't supported anyway, this doesn't make any
      difference.
      
      This makes ide emit the standard disk events and allows kernel event
      polling.  Currently, only MEDIA_CHANGE event is implemented.  Adding
      support for EJECT_REQUEST shouldn't be difficult; however, given that
      ide driver is already deprecated, it probably is best to leave it
      alone.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NJens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-ide@vger.kernel.org
      5b03a1b1
    • T
      block: Don't check events while open is in progress · 69e02c59
      Tejun Heo 提交于
      Not all block drivers clear events immediately after reporting.  Some
      do so in ->revalidate_disk() or other steps during ->open().  There is
      a slim chance event poll may happen between the clearing event check
      from check_disk_change() and the actual clearing of the events which
      would result in spurious events.
      
      Block event checks while block device open is in progress.  There is
      no need to kick explicit event check afterwards as events are always
      checked during open.
      
      -v2: The original patch could have called disk_unblock_events() with
           an already released or %NULL @disk causing oops.  Fixed by making
           sure references are put after disk_unblock_events() is called.
           It also makes the error path of __blkdev_get() a bit simpler.
           This problem was reported by Jens.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      69e02c59
    • T
      block: Don't check events on close unless it was blocked · 6936217c
      Tejun Heo 提交于
      The block event mechanism currently always checks events when the
      device is being closed regardless of the open mode.  The intention was
      to allow detection of EJECT_REQUEST when a device is closed whether
      disk event polling is enabled or not.
      
      This is unnecessary as, for devices of interest, events are checked
      from either userland or kernel and in the former case ->check_events()
      is performed on open of each poll attempt anyway.  Furthermore, this
      unconditional event check on close makes the code susceptible to event
      loop if the block driver doesn't clear reported events correctly - an
      event triggers userland to open and close the device which in turn
      causes another event, rinse and repeat.
      
      Check events on close only if it was blocked by excl write open.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      6936217c
    • T
      block: Don't implicitly trigger event check on disk_unblock_events() · facc31dd
      Tejun Heo 提交于
      Currently, disk_unblock_events() implicitly kick event check if the
      block count reaches zero.  This behavior is not described in the
      comment and hinders with future changes.  Make the unblocker
      explicitly check events by calling disk_check_events() as necessary.
      
      This patch doesn't cause any behavior difference.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      facc31dd
  2. 09 3月, 2011 1 次提交
  3. 08 3月, 2011 3 次提交
  4. 07 3月, 2011 4 次提交
  5. 05 3月, 2011 1 次提交
    • T
      Merge branch 'for-linus' of ../linux-2.6-block into block-for-2.6.39/core · e83a46bb
      Tejun Heo 提交于
      This merge creates two set of conflicts.  One is simple context
      conflicts caused by removal of throtl_scheduled_delayed_work() in
      for-linus and removal of throtl_shutdown_timer_wq() in
      for-2.6.39/core.
      
      The other is caused by commit 255bb490 (block: blk-flush shouldn't
      call directly into q->request_fn() __blk_run_queue()) in for-linus
      crashing with FLUSH reimplementation in for-2.6.39/core.  The conflict
      isn't trivial but the resolution is straight-forward.
      
      * __blk_run_queue() calls in flush_end_io() and flush_data_end_io()
        should be called with @force_kblockd set to %true.
      
      * elv_insert() in blk_kick_flush() should use
        %ELEVATOR_INSERT_REQUEUE.
      
      Both changes are to avoid invoking ->request_fn() directly from
      request completion path and closely match the changes in the commit
      255bb490.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      e83a46bb
  6. 04 3月, 2011 1 次提交
  7. 03 3月, 2011 5 次提交
    • T
      blktrace: Remove blk_fill_rwbs_rq. · 2d3a8497
      Tao Ma 提交于
      If we enable trace events to trace block actions, We use
      blk_fill_rwbs_rq to analyze the corresponding actions
      in request's cmd_flags, but we only choose the minor 2 bits
      from it, so most of other flags(e.g, REQ_SYNC) are missing.
      For example, with a sync write we get:
      write_test-2409  [001]   160.013869: block_rq_insert: 3,64 W 0 () 258135 + =
      8 [write_test]
      
      Since now we have integrated the flags of both bio and request,
      it is safe to pass rq->cmd_flags directly to blk_fill_rwbs and
      blk_fill_rwbs_rq isn't needed any more.
      
      With this patch, after a sync write we get:
      write_test-2417  [000]   226.603878: block_rq_insert: 3,64 WS 0 () 258135 +=
       8 [write_test]
      Signed-off-by: NTao Ma <boyu.mt@taobao.com>
      Acked-by: NJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      2d3a8497
    • V
      block: Move blk_throtl_exit() call to blk_cleanup_queue() · da527770
      Vivek Goyal 提交于
      Move blk_throtl_exit() in blk_cleanup_queue() as blk_throtl_exit() is
      written in such a way that it needs queue lock. In blk_release_queue()
      there is no gurantee that ->queue_lock is still around.
      
      Initially blk_throtl_exit() was in blk_cleanup_queue() but Ingo reported
      one problem.
      
        https://lkml.org/lkml/2010/10/23/86
      
        And a quick fix moved blk_throtl_exit() to blk_release_queue().
      
              commit 7ad58c02
              Author: Jens Axboe <jaxboe@fusionio.com>
              Date:   Sat Oct 23 20:40:26 2010 +0200
      
              block: fix use-after-free bug in blk throttle code
      
      This patch reverts above change and does not try to shutdown the
      throtl work in blk_sync_queue(). By avoiding call to
      throtl_shutdown_timer_wq() from blk_sync_queue(), we should also avoid
      the problem reported by Ingo.
      
      blk_sync_queue() seems to be used only by md driver and it seems to be
      using it to make sure q->unplug_fn is not called as md registers its
      own unplug functions and it is about to free up the data structures
      used by unplug_fn(). Block throttle does not call back into unplug_fn()
      or into md. So there is no need to cancel blk throttle work.
      
      In fact I think cancelling block throttle work is bad because it might
      happen that some bios are throttled and scheduled to be dispatched later
      with the help of pending work and if work is cancelled, these bios might
      never be dispatched.
      
      Block layer also uses blk_sync_queue() during blk_cleanup_queue() and
      blk_release_queue() time. That should be safe as we are also calling
      blk_throtl_exit() which should make sure all the throttling related
      data structures are cleaned up.
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      da527770
    • V
      loop: No need to initialize ->queue_lock explicitly before calling blk_cleanup_queue() · cd25f549
      Vivek Goyal 提交于
      Now we initialize ->queue_lock at queue allocation time so driver does
      not have to worry about initializing it before calling
      blk_cleanup_queue().
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      cd25f549
    • V
      block: Initialize ->queue_lock to internal lock at queue allocation time · c94a96ac
      Vivek Goyal 提交于
      There does not seem to be a clear convention whether q->queue_lock is
      initialized or not when blk_cleanup_queue() is called. In the past it
      was not necessary but now blk_throtl_exit() takes up queue lock by
      default and needs queue lock to be available.
      
      In fact elevator_exit() code also has similar requirement just that it
      is less stringent in the sense that elevator_exit() is called only if
      elevator is initialized.
      
      Two problems have been noticed because of ambiguity about spin lock
      status.
      
            - If a driver calls blk_alloc_queue() and then soon calls
              blk_cleanup_queue() almost immediately, (because some other
      	driver structure allocation failed or some other error happened)
      	then blk_throtl_exit() will run into issues as queue lock is not
      	initialized. Loop driver ran into this issue recently and I
      	noticed error paths in md driver too. Similar error paths should
      	exist in other drivers too.
      
            - If some driver provided external spin lock and zapped the lock
              before blk_cleanup_queue(), then it can lead to issues.
      
      So this patch initializes the default queue lock at queue allocation time.
      
      block throttling code is one of the users of queue lock and it is
      initialized at the queue allocation time, so it makes sense to
      initialize ->queue_lock also to internal lock. A driver can overide that
      lock later. This will take care of the issue where a driver does not have
      to worry about initializing the queue lock to default before calling
      blk_cleanup_queue()
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      c94a96ac
    • L
      block/genhd: Change some numerals into macros · 53f22956
      Liu Yuan 提交于
      Rename the numerals in the diskstats_show() into the macros.
      
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: NLiu Yuan <tailai.ly@taobao.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      53f22956
  8. 02 3月, 2011 6 次提交
  9. 01 3月, 2011 9 次提交