linux-stable.git/drivers/md/bitmap.c, branch linux-3.10.y

md/bitmap: disable bitmap_resize for file-backed bitmaps.

2017-11-02T06:16:18+00:00

commit e8a27f836f165c26f867ece7f31eb5c811692319 upstream.

bitmap_resize() does not work for file-backed bitmaps.
The buffer_heads are allocated and initialized when
the bitmap is read from the file, but resize doesn't
read from the file, it loads from the internal bitmap.
When it comes time to write the new bitmap, the bh is
non-existent and we crash.

The common case when growing an array involves making the array larger,
and that normally means making the bitmap larger.  Doing
that inside the kernel is possible, but would need more code.
It is probably easier to require people who use file-backed
bitmaps to remove them and re-add after a reshape.

So this patch disables the resizing of arrays which have
file-backed bitmaps.  This is better than crashing.

Reported-by: Zhilong Liu 
Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.")
Cc: stable@vger.kernel.org (v3.5+).
Signed-off-by: NeilBrown 
Signed-off-by: Shaohua Li 
Signed-off-by: Willy Tarreau

md/bitmap: return an error when bitmap superblock is corrupt.

2015-08-17T03:51:43+00:00

commit b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49 upstream
    Use separate bitmaps for each nodes in the cluster

bitmap_read_sb() validates the bitmap superblock that it reads in.
If it finds an inconsistency like a bad magic number or out-of-range
version number, it prints an error and returns, but it incorrectly
returns zero, so the array is still assembled with the (invalid) bitmap.

This means it could try to use a bitmap with a new version number which
it therefore does not understand.

This bug was introduced in 3.5 and fix as part of a larger patch in 4.1.
So the patch is suitable for any -stable kernel in that range.

Fixes: 27581e5ae01f ("md/bitmap: centralise allocation of bitmap file pages.")
Signed-off-by: NeilBrown 
Reported-by: GuoQing Jiang

md/bitmap: always wait for writes on unplug.

2015-01-08T17:58:15+00:00

commit 4b5060ddae2b03c5387321fafc089d242225697a upstream.

If two threads call bitmap_unplug at the same time, then
one might schedule all the writes, and the other might
decide that it doesn't need to wait.  But really it does.

It rarely hurts to wait when it isn't absolutely necessary,
and the current code doesn't really focus on 'absolutely necessary'
anyway.  So just wait always.

This can potentially lead to data corruption if a crash happens
at an awkward time and data was written before the bitmap was
updated.  It is very unlikely, but this should go to -stable
just to be safe.  Appropriate for any -stable.

Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: use set_bit_le and clear_bit_le

2013-04-24T01:42:41+00:00

The value returned by test_and_set_bit_le() drivers/md/bitmap.c is not used.
So just use set_bit_le(). The same goes for test_and_clear_bit_le().

Signed-off-by: Akinobu Mita 
Cc: Neil Brown 
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown

new helper: file_inode(file)

2013-02-23T04:31:31+00:00

Signed-off-by: Al Viro

md/bitmap:Don't use IS_ERR to judge alloc_page().

2012-10-11T02:45:36+00:00

Signed-off-by: Jianpeng Ma 
Signed-off-by: NeilBrown

raid: replace list_for_each_continue_rcu with new interface

2012-10-11T02:43:21+00:00

This patch replaces list_for_each_continue_rcu() with
list_for_each_entry_continue_rcu() to save a few lines
of code and allow removing list_for_each_continue_rcu().

Reviewed-by: Paul E. McKenney 
Signed-off-by: Michael Wang 
Signed-off-by: NeilBrown

md/raid1: submit IO from originating thread instead of md thread.

2012-08-01T22:33:20+00:00

queuing writes to the md thread means that all requests go through the
one processor which may not be able to keep up with very high request
rates.

So use the plugging infrastructure to submit all requests on unplug.
If a 'schedule' is needed, we fall back on the old approach of handing
the requests to the thread for it to handle.

Signed-off-by: NeilBrown

md/bitmap: record the space available for the bitmap in the superblock.

2012-05-22T03:55:34+00:00

Now that bitmaps can grow and shrink it is best if we record
how much space is available.  This means that when
we reduce the size of the bitmap we won't "lose" the space
for late when we might want to increase the size of the bitmap
again.

Signed-off-by: NeilBrown

md/bitmap: make sure reshape request are reflected in superblock.

2012-05-22T03:55:26+00:00

As a reshape may change the sync_size and/or chunk_size, we need
to update these whenever we write out the bitmap superblock.

Signed-off-by: NeilBrown