linux-stable.git/drivers/md/bcache, branch linux-3.12.y

bcache: fix cache_set_flush() NULL pointer dereference on OOM

2016-04-11T14:44:17+00:00

commit f8b11260a445169989d01df75d35af0f56178f95 upstream.

When bch_cache_set_alloc() fails to kzalloc the cache_set, the
asyncronous closure handling tries to dereference a cache_set that
hadn't yet been allocated inside of cache_set_flush() which is called
by __cache_set_unregister() during cleanup.  This appears to happen only
during an OOM condition on bcache_register.

Signed-off-by: Eric Wheeler 
Signed-off-by: Jiri Slaby

bcache: unregister reboot notifier if bcache fails to unregister device

2016-03-03T11:45:51+00:00

commit 2ecf0cdb2b437402110ab57546e02abfa68a716b upstream.

In bcache_init() function it forgot to unregister reboot notifier if
bcache fails to unregister a block device.  This commit fixes this.

Signed-off-by: Zheng Liu 
Tested-by: Joshua Schmid 
Tested-by: Eric Wheeler 
Cc: Kent Overstreet 
Signed-off-by: Jens Axboe 
Signed-off-by: Jiri Slaby

bcache: fix a leak in bch_cached_dev_run()

2016-03-03T11:45:51+00:00

commit 4d4d8573a8451acc9f01cbea24b7e55f04a252fe upstream.

Signed-off-by: Al Viro 
Tested-by: Joshua Schmid 
Tested-by: Eric Wheeler 
Cc: Kent Overstreet 
Signed-off-by: Jens Axboe 
Signed-off-by: Jiri Slaby

bcache: Make sure to pass GFP_WAIT to mempool_alloc()

2015-01-29T14:44:53+00:00

commit bcf090e0040e30f8409e6a535a01e6473afb096f upstream.

this was very wrong - mempool_alloc() only guarantees success with GFP_WAIT.
bcache uses GFP_NOWAIT in various other places where we have a fallback,
circuits must've gotten crossed when writing this code or something.

Signed-off-by: Kent Overstreet 
Cc: Gabriel de Perthuis 
Signed-off-by: Jiri Slaby

bcache: fix crash with incomplete cache set

2014-10-31T11:14:36+00:00

commit bf0c55c986540483c34ca640f2eef4c3314388b1 upstream.

Change-Id: I6abde52afe917633480caaf4e2518f42a816d886
Signed-off-by: Jiri Slaby

bcache: fix memory corruption in init error path

2014-10-31T11:14:35+00:00

commit c9a78332b42cbdcdd386a95192a716b67d1711a4 upstream.

If register_cache_set() failed, we would touch ca->set after
it had already been freed. Also, fix an assertion to catch
this.

Change-Id: I748e5f5b223e2d9b2602075dec2f997cced2394d
Signed-off-by: Jiri Slaby

bcache: Correct printing of btree_gc_max_duration_ms

2014-10-31T11:14:35+00:00

commit 5b25abade29616d42d60f9bd5e6a5ad07f7314e3 upstream.

time_stats::btree_gc_max_duration_mc is not bit shifted by 8

Fixes BUG #138

Change-Id: I44fc6e1d0579674016acc533f1a546b080e5371a
Signed-off-by: Surbhi Palande 
Signed-off-by: Jiri Slaby

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