linux-toradex.git/drivers/md/bcache, branch v3.10.78

bcache: Data corruption fix

2014-02-06T19:08:16+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: Fixed incorrect order of arguments to bio_alloc_bioset()

2013-11-13T03:05:30+00:00

commit d4eddd42f592a0cf06818fae694a3d271f842e4d upstream.

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

bcache: Fix a null ptr deref regression

2013-10-13T23:08:35+00:00

commit 2fe80d3bbf1c8bd9efc5b8154207c8dd104e7306 upstream.

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 
Reported-by: Gabriel de Perthuis 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

bcache: Fix flushes in writeback mode

2013-10-05T14:13:09+00:00

commit c0f04d88e46d14de51f4baebb6efafb7d59e9f96 upstream.

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 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

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

2013-10-05T14:13:09+00:00

commit 84786438ed17978d72eeced580ab757e4da8830b upstream.

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 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

bcache: Fix a shrinker deadlock

2013-10-05T14:13:09+00:00

commit a698e08c82dfb9771e0bac12c7337c706d729b6d upstream.

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 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

bcache: Fix a dumb CPU spinning bug in writeback

2013-10-05T14:13:09+00:00

commit 79e3dab90d9f826ceca67c7890e048ac9169de49 upstream.

schedule_timeout() != schedule_timeout_uninterruptible()

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

bcache: Fix a flush/fua performance bug

2013-10-05T14:13:09+00:00

commit 1394d6761b6e9e15ee7c632a6d48791188727b40 upstream.

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 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

bcache: Fix a writeback performance regression

2013-10-05T14:13:09+00:00

commit c2a4f3183a1248f615a695fbd8905da55ad11bba upstream.

Background writeback works by scanning the btree for dirty data and
adding those keys into a fixed size buffer, then for each dirty key in
the keybuf writing it to the backing device.

When read_dirty() finishes and it's time to scan for more dirty data, we
need to wait for the outstanding writeback IO to finish - they still
take up slots in the keybuf (so that foreground writes can check for
them to avoid races) - without that wait, we'll continually rescan when
we'll be able to add at most a key or two to the keybuf, and that takes
locks that starves foreground IO.  Doh.

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

bcache: Fix for when no journal entries are found

2013-10-05T14:13:09+00:00

commit c426c4fd46f709ade2bddd51c5738729c7ae1db5 upstream.

The journal replay code didn't handle this case, causing it to go into
an infinite loop...

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