Skip to content

L
linux
Switch branch/tag
  1. 10 Sep, 2011 2 commits
    • NeilBrown's avatar
      md/raid10: unify handling of write completion. · 19d5f834
      NeilBrown authored 
      A write can complete at two different places:
1/ when the last member-device write completes, through
   raid10_end_write_request
2/ in make_request() when we remove the initial bias from ->remaining.

These two should do exactly the same thing and the comment says they
do, but they don't.

So factor the correct code out into a function and call it in both
places.  This makes the code much more similar to RAID1.

The difference is only significant if there is an error, and they
usually take a while, so it is unlikely that there will be an error
already when make_request is completing, so this is unlikely to cause
real problems.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      19d5f834
    • NeilBrown's avatar
      Avoid dereferencing a 'request_queue' after last close. · 94007751
      NeilBrown authored 
      On the last close of an 'md' device which as been stopped, the device
is destroyed and in particular the request_queue is freed.  The free
is done in a separate thread so it might happen a short time later.

__blkdev_put calls bdev_inode_switch_bdi *after* ->release has been
called.

Since commit f758eeab
bdev_inode_switch_bdi will dereference the 'old' bdi, which lives
inside a request_queue, to get a spin lock.  This causes the last
close on an md device to sometime take a spin_lock which lives in
freed memory - which results in an oops.

So move the called to bdev_inode_switch_bdi before the call to
->release.

Cc: Christoph Hellwig <hch@lst.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Acked-by: default avatarWu Fengguang <fengguang.wu@intel.com>
Cc: stable@kernel.org
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      94007751
  3. 31 Aug, 2011 1 commit
    • NeilBrown's avatar
      md/raid5: fix a hang on device failure. · 43220aa0
      NeilBrown authored 
      Waiting for a 'blocked' rdev to become unblocked in the raid5d thread
cannot work with internal metadata as it is the raid5d thread which
will clear the blocked flag.
This wasn't a problem in 3.0 and earlier as we only set the blocked
flag when external metadata was used then.
However we now set it always, so we need to be more careful.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      43220aa0
  5. 30 Aug, 2011 1 commit
  7. 25 Aug, 2011 4 commits
  9. 24 Aug, 2011 1 commit
  11. 23 Aug, 2011 10 commits
  13. 22 Aug, 2011 11 commits
  15. 21 Aug, 2011 4 commits
  17. 20 Aug, 2011 4 commits
  19. 19 Aug, 2011 2 commits
    • Jiaying Zhang's avatar
      ext4: flush any pending end_io requests before DIO reads w/dioread_nolock · dccaf33f
      Jiaying Zhang authored 
      There is a race between ext4 buffer write and direct_IO read with
dioread_nolock mount option enabled. The problem is that we clear
PageWriteback flag during end_io time but will do
uninitialized-to-initialized extent conversion later with dioread_nolock.
If an O_direct read request comes in during this period, ext4 will return
zero instead of the recently written data.

This patch checks whether there are any pending uninitialized-to-initialized
extent conversion requests before doing O_direct read to close the race.
Note that this is just a bandaid fix. The fundamental issue is that we
clear PageWriteback flag before we really complete an IO, which is
problem-prone. To fix the fundamental issue, we may need to implement an
extent tree cache that we can use to look up pending to-be-converted extents.
Signed-off-by: default avatarJiaying Zhang <jiayingz@google.com>
Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
Cc: stable@kernel.org
      dccaf33f
    • Jesse Barnes's avatar
      drm/i915: set GFX_MODE to pre-Ivybridge default value even on Ivybridge · b095cd0a
      Jesse Barnes authored 
      Prior to Ivybridge, the GFX_MODE would default to 0x800, meaning that
MI_FLUSH would flush the TLBs in addition to the rest of the caches
indicated in the MI_FLUSH command.  However starting with Ivybridge, the
register defaults to 0x2800 out of reset, meaning that to invalidate the
TLB we need to use PIPE_CONTROL.  Since we're not doing that yet, go
back to the old default so things work.

v2: don't forget to actually *clear* the new bit
Reviewed-by: default avatarEric Anholt <eric@anholt.net>
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Tested-by: default avatarKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      b095cd0a
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7