1. 24 Oct, 2011 3 commits
    • Tejun Heo's avatar
      block: make gendisk hold a reference to its queue · f992ae80
      Tejun Heo authored
      The following command sequence triggers an oops.
      
      # mount /dev/sdb1 /mnt
      # echo 1 > /sys/class/scsi_device/0\:0\:1\:0/device/delete
      # umount /mnt
      
       general protection fault: 0000 [#1] PREEMPT SMP
       CPU 2
       Modules linked in:
      
       Pid: 791, comm: umount Not tainted 3.1.0-rc3-work+ #8 Bochs Bochs
       RIP: 0010:[<ffffffff810d0879>]  [<ffffffff810d0879>] __lock_acquire+0x389/0x1d60
      ...
       Call Trace:
        [<ffffffff810d2845>] lock_acquire+0x95/0x140
        [<ffffffff81aed87b>] _raw_spin_lock+0x3b/0x50
        [<ffffffff811573bc>] bdi_lock_two+0x5c/0x70
        [<ffffffff811c2f6c>] bdev_inode_switch_bdi+0x4c/0xf0
        [<ffffffff811c3fcb>] __blkdev_put+0x11b/0x1d0
        [<ffffffff811c4010>] __blkdev_put+0x160/0x1d0
        [<ffffffff811c40df>] blkdev_put+0x5f/0x190
        [<ffffffff8118f18d>] kill_block_super+0x4d/0x80
        [<ffffffff8118f4a5>] deactivate_locked_super+0x45/0x70
        [<ffffffff8119003a>] deactivate_super+0x4a/0x70
        [<ffffffff811ac4ad>] mntput_no_expire+0xed/0x130
        [<ffffffff811acf2e>] sys_umount+0x7e/0x3a0
        [<ffffffff81aeeeab>] system_call_fastpath+0x16/0x1b
      
      This is because bdev holds on to disk but disk doesn't pin the
      associated queue.  If a SCSI device is removed while the device is
      still open, the sdev puts the base reference to the queue on release.
      When the bdev is finally released, the associated queue is already
      gone along with the bdi and bdev_inode_switch_bdi() ends up
      dereferencing already freed bdi.
      
      Even if it were not for this bug, disk not holding onto the associated
      queue is very unusual and error-prone.
      
      Fix it by making add_disk() take an extra reference to its queue and
      put it on disk_release() and ensuring that disk and its fops owner are
      put in that order after all accesses to the disk and queue are
      complete.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      f992ae80
    • Jeff Moyer's avatar
      blk-flush: move the queue kick into · e67b77c7
      Jeff Moyer authored
      A dm-multipath user reported[1] a problem when trying to boot
      a kernel with commit 4853abaa
      (block: fix flush machinery for stacking drivers with differring
      flush flags) applied.  It turns out that an empty flush request
      can be sent into blk_insert_flush.  When the BUG_ON was fixed
      to allow for this, I/O on the underlying device would stall.  The
      reason is that blk_insert_cloned_request does not kick the queue.
      In the aforementioned commit, I had added a special case to
      kick the queue if data was sent down but the queue flags did
      not require a flush.  A better solution is to push the queue
      kick up into blk_insert_cloned_request.
      
      This patch, along with a follow-on which fixes the BUG_ON, fixes
      the issue reported.
      
      [1] http://www.redhat.com/archives/dm-devel/2011-September/msg00154.htmlReported-by: default avatarChristophe Saout <christophe@saout.de>
      Signed-off-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      
      Stable note: 3.1
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      e67b77c7
    • Jeff Moyer's avatar
      blk-flush: fix invalid BUG_ON in blk_insert_flush · 834f9f61
      Jeff Moyer authored
      A user reported a regression due to commit
      4853abaa (block: fix flush
      machinery for stacking drivers with differring flush flags).
      Part of the problem is that blk_insert_flush required a
      single bio be attached to the request.  In reality, having
      no attached bio is also a valid case, as can be observed with
      an empty flush.
      
      [1] http://www.redhat.com/archives/dm-devel/2011-September/msg00154.htmlReported-by: default avatarChristophe Saout <christophe@saout.de>
      Signed-off-by: Jeff Moyer <jmoyer@redhat.com
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      
      Stable note: 3.1
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      834f9f61
  2. 17 Oct, 2011 1 commit
    • Christoph Hellwig's avatar
      loop: remove the incorrect write_begin/write_end shortcut · 456be148
      Christoph Hellwig authored
      Currently the loop device tries to call directly into write_begin/write_end
      instead of going through ->write if it can.  This is a fairly nasty shortcut
      as write_begin and write_end are only callbacks for the generic write code
      and expect to be called with filesystem specific locks held.
      
      This code currently causes various issues for clustered filesystems as it
      doesn't take the required cluster locks, and it also causes issues for XFS
      as it doesn't properly lock against the swapext ioctl as called by the
      defragmentation tools.  This in case causes data corruption if
      defragmentation hits a busy loop device in the wrong time window, as
      reported by RH QA.
      
      The reason why we have this shortcut is that it saves a data copy when
      doing a transformation on the loop device, which is the technical term
      for using cryptoloop (or an XOR transformation).  Given that cryptoloop
      has been deprecated in favour of dm-crypt my opinion is that we should
      simply drop this shortcut instead of finding complicated ways to to
      introduce a formal interface for this shortcut.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      456be148
  3. 16 Oct, 2011 1 commit
  4. 15 Oct, 2011 3 commits
  5. 14 Oct, 2011 6 commits
  6. 13 Oct, 2011 7 commits
  7. 11 Oct, 2011 5 commits
  8. 10 Oct, 2011 11 commits
  9. 08 Oct, 2011 2 commits
  10. 07 Oct, 2011 1 commit