linux-stable.git/drivers/md/bcache, branch v3.12.28

bcache: Minor journal fix

2014-09-02T09:20:15+00:00

commit b3fa7e77e67e647db3db2166b65083a427d84ed3 upstream.

The real fix is where we check the bytes we need against how much is
remaining - we also need to check for a journal entry bigger than our
buffer, we'll never write those and it would be bad if we tried to read
one.

Also improve the diagnostic messages.

Signed-off-by: Kent Overstreet 
Signed-off-by: Jiri Slaby

bcache: Data corruption fix

2014-02-06T19:22:19+00:00

commit ef71ec00002d92a08eb27e9d036e3d48835b6597 upstream.

The code that handles overlapping extents that we've just read back in from disk
was depending on the behaviour of the code that handles overlapping extents as
we're inserting into a btree node in the case of an insert that forced an
existing extent to be split: on insert, if we had to split we'd also insert a
new extent to represent the top part of the old extent - and then that new
extent would get written out.

The code that read the extents back in thus not bother with splitting extents -
if it saw an extent that ovelapped in the middle of an older extent, it would
trim the old extent to only represent the bottom part, assuming that the
original insert would've inserted a new extent to represent the top part.

I still haven't figured out _how_ it can happen, but I'm now pretty convinced
(and testing has confirmed) that there's some kind of an obscure corner case
(probably involving extent merging, and multiple overwrites in different sets)
that breaks this. The fix is to change the mergesort fixup code to split extents
itself when required.

Signed-off-by: Kent Overstreet 
Signed-off-by: Greg Kroah-Hartman

bcache: Fix dirty_data accounting

2013-12-04T19:05:38+00:00

commit 1fa8455deb92e9ec7756df23030e73b2d28eeca7 upstream.

Dirty data accounting wasn't quite right - firstly, we were adding the key we're
inserting after it could have merged with another dirty key already in the
btree, and secondly we could sometimes pass the wrong offset to
bcache_dev_sectors_dirty_add() for dirty data we were overwriting - which is
important when tracking dirty data by stripe.

Signed-off-by: Kent Overstreet 
Signed-off-by: Greg Kroah-Hartman

bcache: Fixed incorrect order of arguments to bio_alloc_bioset()

2013-10-23T06:55:36+00:00

Signed-off-by: Kent Overstreet 
Cc: linux-stable  # >= v3.10
Signed-off-by: Linus Torvalds

bcache: Fix a null ptr deref regression

2013-10-11T01:17:39+00:00

Commit c0f04d88e46d ("bcache: Fix flushes in writeback mode") was fixing
a reported data corruption bug, but it seems some last minute
refactoring or rebasing introduced a null pointer deref.

Signed-off-by: Kent Overstreet 
Cc: linux-stable  # >= v3.10
Reported-by: Gabriel de Perthuis 
Signed-off-by: Linus Torvalds

bcache: Fix flushes in writeback mode

2013-09-24T21:41:43+00:00

In writeback mode, when we get a cache flush we need to make sure we
issue a flush to the backing device.

The code for sending down an extra flush was wrong - by cloning the bio
we were probably getting flags that didn't make sense for a bare flush,
and also the old code was firing for FUA bios, for which we don't need
to send a flush to the backing device.

This was causing data corruption somehow - the mechanism was never
determined, but this patch fixes it for the users that were seeing it.

Signed-off-by: Kent Overstreet 
Cc: linux-stable  # >= v3.10
Signed-off-by: Linus Torvalds

bcache: Fix for handling overlapping extents when reading in a btree node

2013-09-24T21:41:43+00:00

btree_sort_fixup() was overly clever, because it was trying to avoid
pulling a key off the btree iterator in more than one place.

This led to a really obscure bug where we'd break early from the loop in
btree_sort_fixup() if the current key overlapped with keys in more than
one older set, and the next key it overlapped with was zero size.

Signed-off-by: Kent Overstreet 
Cc: linux-stable  # >= v3.10
Signed-off-by: Linus Torvalds

bcache: Fix a shrinker deadlock

2013-09-24T21:41:43+00:00

GFP_NOIO means we could be getting called recursively - mca_alloc() ->
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.

Signed-off-by: Kent Overstreet 
Cc: linux-stable  # >= v3.10
Signed-off-by: Linus Torvalds

bcache: Fix a dumb CPU spinning bug in writeback

2013-09-24T21:41:43+00:00

schedule_timeout() != schedule_timeout_uninterruptible()

Signed-off-by: Kent Overstreet 
Cc: linux-stable  # >= v3.10
Signed-off-by: Linus Torvalds

bcache: Fix a flush/fua performance bug

2013-09-24T21:41:43+00:00

bch_journal_meta() was missing the flush to make the journal write
actually go down (instead of waiting up to journal_delay_ms)...

Whoops

Signed-off-by: Kent Overstreet 
Cc: linux-stable  # >= v3.10
Signed-off-by: Linus Torvalds