Before this line of code cbt->count is always > 0 as it is:
symmetrically incremented/decremented in this function under cbt->lock,
and we are at the point just before decrementing it. This means that
!cbt->count-- (note: postfix decrement returns value before operation)
is always false and we neve
We have a cbt->cache percpu allocation leak detected by kmemleak, which
might be caused by these uncalled release callbacks.
This applies cleanly to vz7 and vz9, we need both.
https://jira.sw.ru/browse/PSBM-141114
Pavel Tikhomirov (2):
blk-cbt: fix count decrement and check in cbt_page_alloc
Calling cpt_release_callback on cbt->count != 0 here is really strange
because cbt_page_alloc would anyway do it on decrementing count to zero,
but in opposite case where cbt->count == 0 we should call the callback
but we do not, let's fix it by reversing the condition.
We have a cbt->cache percpu
On 02.11.2022 03:32, Kui Liu wrote:
-Original Message-
From: Alexander Atanasov
Date: Tuesday, 1 November 2022 at 11:57 PM
To: Konstantin Khorenko , "Denis V. Lunev"
, Devel
Cc: Kui Liu , Alexey Kuznetsov
Subject: Re: [PATCH vz9 v2] ploop: port and fix the standby mode feature.
Hello,
On 2.11.22 4:32, Kui Liu wrote:
[snip]
[LIU]: QUEUE_FLAG_STANDBY bit MUST be cleared here, as it is the only place
where
the ploop device recovers from standby mode. In our use case, once a ploop
device enters standby
mode, the userspace will initiate recovery by replacing the t
On 19.10.22 9:58, Kui Liu wrote:
> >
> > + if (blk_queue_standby_en(ploop_blk_queue(ploop))) {
> > + blk_queue_flag_clear(QUEUE_FLAG_STANDBY,
ploop_blk_queue(ploop));
> > + if
(!static_key_enabled(&ploop_sta
The commit is pushed to "branch-rh7-3.10.0-1160.59.1.vz7.186.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-1160.59.1.vz7.186.2
-->
commit 8b86220f51f978f157f9fb4008169e5c9b7640cf
Author: Konstantin Khorenko
Date: Tue Apr 26 16:32:33 2022 +0300
m
During ip route save we may get flags
RTNH_F_DEAD and RTNH_F_LINKDOWN in final dump image.
But we can't set these flags back during restore, because
these flags calculated dynamically in the kernel. It's
an inconsistency between NLM_F_DUMP and NLM_F_CREATE.
It's fully safe to workaround it just by
