linux-stable.git/drivers/md, branch v4.1.44

md/raid5: add thread_group worker async_tx_issue_pending_all

2017-09-10T20:35:46+00:00

[ Upstream commit 7e96d559634b73a8158ee99a7abece2eacec2668 ]

Since thread_group worker and raid5d kthread are not in sync, if
worker writes stripe before raid5d then requests will be waiting
for issue_pendig.

Issue observed when building raid5 with ext4, in some build runs
jbd2 would get hung and requests were waiting in the HW engine
waiting to be issued.

Fix this by adding a call to async_tx_issue_pending_all in the
raid5_do_work.

Signed-off-by: Ofer Heifetz 
Cc: stable@vger.kernel.org
Signed-off-by: Shaohua Li 
Signed-off-by: Sasha Levin

Raid5 should update rdev->sectors after reshape

2017-09-10T14:59:17+00:00

[ Upstream commit b5d27718f38843a74552e9a93d32e2391fd3999f ]

The raid5 md device is created by the disks which we don't use the total size. For example,
the size of the device is 5G and it just uses 3G of the devices to create one raid5 device.
Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid
and assemble it again. It fails.
mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean
mdadm /dev/md0 --grow --chunk=64
wait reshape to finish
mdadm -S /dev/md0
mdadm -As
The error messages:
[197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing!
[197519.821686] md: md_import_device returned -22

After reshape the data offset is changed. It selects backwards direction in this condition.
In function super_1_load it compares the available space of the underlying device with
sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL.
rdev->sectors is updated in md_finish_reshape. Then sb->data_size is set in super_1_sync based
on rdev->sectors. So add md_finish_reshape in end_reshape.

Signed-off-by: Xiao Ni 
Acked-by: Guoqing Jiang 
Cc: stable@vger.kernel.org
Signed-off-by: Shaohua Li 
Signed-off-by: Sasha Levin

md: don't use flush_signals in userspace processes

2017-09-10T14:59:17+00:00

[ Upstream commit f9c79bc05a2a91f4fba8bfd653579e066714b1ec ]

The function flush_signals clears all pending signals for the process. It
may be used by kernel threads when we need to prepare a kernel thread for
responding to signals. However using this function for an userspaces
processes is incorrect - clearing signals without the program expecting it
can cause misbehavior.

The raid1 and raid5 code uses flush_signals in its request routine because
it wants to prepare for an interruptible wait. This patch drops
flush_signals and uses sigprocmask instead to block all signals (including
SIGKILL) around the schedule() call. The signals are not lost, but the
schedule() call won't respond to them.

Signed-off-by: Mikulas Patocka 
Cc: stable@vger.kernel.org
Acked-by: NeilBrown 
Signed-off-by: Shaohua Li 
Signed-off-by: Sasha Levin

md: fix super_offset endianness in super_1_rdev_size_change

2017-07-31T17:37:53+00:00

[ Upstream commit 3fb632e40d7667d8bedfabc28850ac06d5493f54 ]

The sb->super_offset should be big-endian, but the rdev->sb_start is in
host byte order, so fix this by adding cpu_to_le64.

Signed-off-by: Jason Yan 
Signed-off-by: Shaohua Li 
Signed-off-by: Sasha Levin

md:raid1: fix a dead loop when read from a WriteMostly disk

2017-06-13T13:29:18+00:00

[ Upstream commit 816b0acf3deb6d6be5d0519b286fdd4bafade905 ]

If first_bad == this_sector when we get the WriteMostly disk
in read_balance(), valid disk will be returned with zero
max_sectors. It'll lead to a dead loop in make_request(), and
OOM will happen because of endless allocation of struct bio.

Since we can't get data from this disk in this case, so
continue for another disk.

Signed-off-by: Wei Fang 
Signed-off-by: Shaohua Li 
Signed-off-by: Sasha Levin

dm bufio: make the parameter "retain_bytes" unsigned long

2017-06-08T10:12:46+00:00

[ Upstream commit 13840d38016203f0095cd547b90352812d24b787 ]

Change the type of the parameter "retain_bytes" from unsigned to
unsigned long, so that on 64-bit machines the user can set more than
4GiB of data to be retained.

Also, change the type of the variable "count" in the function
"__evict_old_buffers" to unsigned long.  The assignment
"count = c->n_buffers[LIST_CLEAN] + c->n_buffers[LIST_DIRTY];"
could result in unsigned long to unsigned overflow and that could result
in buffers not being freed when they should.

While at it, avoid division in get_retain_buffers().  Division is slow,
we can change it to shift because we have precalculated the log2 of
block size.

Cc: stable@vger.kernel.org
Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin

dm space map disk: fix some book keeping in the disk space map

2017-06-08T10:12:19+00:00

[ Upstream commit 0377a07c7a035e0d033cd8b29f0cb15244c0916a ]

When decrementing the reference count for a block, the free count wasn't
being updated if the reference count went to zero.

Cc: stable@vger.kernel.org
Signed-off-by: Joe Thornber 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin

dm thin metadata: call precommit before saving the roots

2017-06-08T10:12:19+00:00

[ Upstream commit 91bcdb92d39711d1adb40c26b653b7978d93eb98 ]

These calls were the wrong way round in __write_initial_superblock.

Cc: stable@vger.kernel.org
Signed-off-by: Joe Thornber 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin

dm bufio: check new buffer allocation watermark every 30 seconds

2017-05-17T19:08:24+00:00

[ Upstream commit 390020ad2af9ca04844c4f3b1f299ad8746d84c8 ]

dm-bufio checks a watermark when it allocates a new buffer in
__bufio_new().  However, it doesn't check the watermark when the user
changes /sys/module/dm_bufio/parameters/max_cache_size_bytes.

This may result in a problem - if the watermark is high enough so that
all possible buffers are allocated and if the user lowers the value of
"max_cache_size_bytes", the watermark will never be checked against the
new value because no new buffer would be allocated.

To fix this, change __evict_old_buffers() so that it checks the
watermark.  __evict_old_buffers() is called every 30 seconds, so if the
user reduces "max_cache_size_bytes", dm-bufio will react to this change
within 30 seconds and decrease memory consumption.

Depends-on: 1b0fb5a5b2 ("dm bufio: avoid a possible ABBA deadlock")
Cc: stable@vger.kernel.org
Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin

dm bufio: avoid a possible ABBA deadlock

2017-05-17T19:08:24+00:00

[ Upstream commit 1b0fb5a5b2dc0dddcfa575060441a7176ba7ac37 ]

__get_memory_limit() tests if dm_bufio_cache_size changed and calls
__cache_size_refresh() if it did.  It takes dm_bufio_clients_lock while
it already holds the client lock.  However, lock ordering is violated
because in cleanup_old_buffers() dm_bufio_clients_lock is taken before
the client lock.

This results in a possible deadlock and lockdep engine warning.

Fix this deadlock by changing mutex_lock() to mutex_trylock().  If the
lock can't be taken, it will be re-checked next time when a new buffer
is allocated.

Also add "unlikely" to the if condition, so that the optimizer assumes
that the condition is false.

Cc: stable@vger.kernel.org
Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin