1. 03 Mar, 2011 2 commits
    • Petr Uzel's avatar
      block: kill loop_mutex · fd51469f
      Petr Uzel authored
      Following steps lead to deadlock in kernel:
      
      dd if=/dev/zero of=img bs=512 count=1000
      losetup -f img
      mkfs.ext2 /dev/loop0
      mount -t ext2 -o loop /dev/loop0 mnt
      umount mnt/
      
      Stacktrace:
      [<c102ec04>] irq_exit+0x36/0x59
      [<c101502c>] smp_apic_timer_interrupt+0x6b/0x75
      [<c127f639>] apic_timer_interrupt+0x31/0x38
      [<c101df88>] mutex_spin_on_owner+0x54/0x5b
      [<fe2250e9>] lo_release+0x12/0x67 [loop]
      [<c10c4eae>] __blkdev_put+0x7c/0x10c
      [<c10a4da5>] fput+0xd5/0x1aa
      [<fe2250cf>] loop_clr_fd+0x1a9/0x1b1 [loop]
      [<fe225110>] lo_release+0x39/0x67 [loop]
      [<c10c4eae>] __blkdev_put+0x7c/0x10c
      [<c10a59d9>] deactivate_locked_super+0x17/0x36
      [<c10b6f37>] sys_umount+0x27e/0x2a5
      [<c10b6f69>] sys_oldumount+0xb/0xe
      [<c1002897>] sysenter_do_call+0x12/0x26
      [<ffffffff>] 0xffffffff
      
      Regression since 2a48fc0a, which introduced the private
      loop_mutex as part of the BKL removal process.
      
      As per [1], the mutex can be safely removed.
      
      [1] http://www.gossamer-threads.com/lists/linux/kernel/1341930
      
      Addresses: https://bugzilla.novell.com/show_bug.cgi?id=669394
      Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=29172Signed-off-by: default avatarPetr Uzel <petr.uzel@suse.cz>
      Cc: stable@kernel.org
      Reviewed-by: default avatarNikanth Karthikesan <knikanth@suse.de>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      fd51469f
    • Tao Ma's avatar
      blktrace: Remove blk_fill_rwbs_rq. · 2d3a8497
      Tao Ma authored
      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: default avatarTao Ma <boyu.mt@taobao.com>
      Acked-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      2d3a8497
  2. 02 Mar, 2011 2 commits
    • Tejun Heo's avatar
      block: blk-flush shouldn't call directly into q->request_fn() __blk_run_queue() · 255bb490
      Tejun Heo authored
      blk-flush decomposes a flush into sequence of multiple requests.  On
      completion of a request, the next one is queued; however, block layer
      must not implicitly call into q->request_fn() directly from completion
      path.  This makes the queue behave unexpectedly when seen from the
      drivers and violates the assumption that q->request_fn() is called
      with process context + queue_lock.
      
      This patch makes blk-flush the following two changes to make sure
      q->request_fn() is not called directly from request completion path.
      
      - blk_flush_complete_seq_end_io() now asks __blk_run_queue() to always
        use kblockd instead of calling directly into q->request_fn().
      
      - queue_next_fseq() uses ELEVATOR_INSERT_REQUEUE instead of
        ELEVATOR_INSERT_FRONT so that elv_insert() doesn't try to unplug the
        request queue directly.
      
      Reported by Jan in the following threads.
      
       http://thread.gmane.org/gmane.linux.ide/48778
       http://thread.gmane.org/gmane.linux.ide/48786
      
      stable: applicable to v2.6.37.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarJan Beulich <JBeulich@novell.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      255bb490
    • Tejun Heo's avatar
      block: add @force_kblockd to __blk_run_queue() · 1654e741
      Tejun Heo authored
      __blk_run_queue() automatically either calls q->request_fn() directly
      or schedules kblockd depending on whether the function is recursed.
      blk-flush implementation needs to be able to explicitly choose
      kblockd.  Add @force_kblockd.
      
      All the current users are converted to specify %false for the
      parameter and this patch doesn't introduce any behavior change.
      
      stable: This is prerequisite for fixing ide oops caused by the new
              blk-flush implementation.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      1654e741
  3. 01 Mar, 2011 12 commits
  4. 28 Feb, 2011 6 commits
  5. 26 Feb, 2011 4 commits
  6. 25 Feb, 2011 14 commits