The patch reverts:
Subject: [PATCH rh7] ploop: push_backup must pass READs intact
If push_backup is in progress (doesn't matter "full" or "incremental") and
ploop state-machine detects incoming WRITE request to the cluster-block that
was not push_backup-ed yet, it suspends the request until users
It was not very nice idea to reuse plo->lockout_tree for push_backup. Because
by design only one preq (for any given req_cluster) can sit in the lockout
tree, but while we're reusing the tree for a WRITE request, a READ from
backup tool may come. Such a READ may want to to use the tree: see how
map
The patch set firstly reverts ALLOW_READS hack that was needed to
reuse plo->lockout_tree for push_backup needs, then adds new lockout
tree for push_backup needs: plo->lockout_pb_tree.
This solves an issue revealed by PSBM-47680: it is possible that
plo->lockout_tree is already occupied by a WRITE
Changelog:
OpenVZ kernel rh7-3.10.0-327.18.2.vz7.14.11
* pfcache: abort ext4_pfcache_open if inode already has peer installed
to avoid i_peer_list corruption
* mm: fix PAGE_KMEMCG_MAPCOUNT_VALUE not to intersect with balloon pages
* net: packet: rework rx/tx ring pages accounting
Generated
The commit is pushed to "branch-rh7-3.10.0-327.18.2.vz7.14.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-327.18.2.vz7.14.10
-->
commit cefaca838039a6d306791a29c9984be56cc6e7f2
Author: Vladimir Davydov
Date: Thu Jun 2 19:06:30 2016 +0400
pfcache:
The commit is pushed to "branch-rh7-3.10.0-327.18.2.vz7.14.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-327.18.2.vz7.14.10
-->
commit 2edb1b3f01b5445d2a7a4fa951cad7f3e1d8a485
Author: Vladimir Davydov
Date: Thu Jun 2 19:06:29 2016 +0400
net: pac
The commit is pushed to "branch-rh7-3.10.0-327.18.2.vz7.14.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-327.18.2.vz7.14.10
-->
commit fe8488c82bb11b53fe75e38642ca4c7c274fd5c0
Author: Vladimir Davydov
Date: Thu Jun 2 19:06:29 2016 +0400
ve/mm: f
To account tx/rx ring pages to kmemcg, we allocate them with
__GFP_ACCOUNT. After commit 1265d3474391 ("mm: charge/uncharge kmemcg
from generic page allocator paths") this implies that these pages have
PAGE_KMEMCG_MAPCOUNT_VALUE stored in page->_mapcount. This is incorrect
as these pages are suppos
It should be -512, -256 is used for balloon pages.
Fixes: 1265d3474391 ("mm: charge/uncharge kmemcg from generic page allocator
paths")
Signed-off-by: Vladimir Davydov
---
include/linux/page-flags.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/page-flags.h b
