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

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

dm ioctl: prevent stack leak in dm ioctl call

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

[ Upstream commit 4617f564c06117c7d1b611be49521a4430042287 ]

When calling a dm ioctl that doesn't process any data
(IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct
dm_ioctl are left initialized.  Current code is incorrectly extending
the size of data copied back to user, causing the contents of kernel
stack to be leaked to user.  Fix by only copying contents before data
and allow the functions processing the ioctl to override.

Cc: stable@vger.kernel.org
Signed-off-by: Adrian Salido 
Reviewed-by: Alasdair G Kergon 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin

dm era: save spacemap metadata root after the pre-commit

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

[ Upstream commit 117aceb030307dcd431fdcff87ce988d3016c34a ]

When committing era metadata to disk, it doesn't always save the latest
spacemap metadata root in superblock. Due to this, metadata is getting
corrupted sometimes when reopening the device. The correct order of update
should be, pre-commit (shadows spacemap root), save the spacemap root
(newly shadowed block) to in-core superblock and then the final commit.

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

dm btree: fix for dm_btree_find_lowest_key()

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

[ Upstream commit 7d1fedb6e96a960aa91e4ff70714c3fb09195a5a ]

dm_btree_find_lowest_key() is giving incorrect results.  find_key()
traverses the btree correctly for finding the highest key, but there is
an error in the way it traverses the btree for retrieving the lowest
key.  dm_btree_find_lowest_key() fetches the first key of the rightmost
block of the btree instead of fetching the first key from the leftmost
block.

Fix this by conditionally passing the correct parameter to value64()
based on the @find_highest flag.

Cc: stable@vger.kernel.org
Signed-off-by: Erez Zadok 
Signed-off-by: Vinothkumar Raja 
Signed-off-by: Nidhi Panpalia 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin