All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
To: "Denis V. Lunev" <den@openvz.org>, svt-core@virtuozzo.com
Subject: Re: [PATCH hci-8.0 2/2] migration/cpr: lock the ramblocks #VSTOR-145529
Date: Wed, 16 Sep 2026 20:18:52 +0300	[thread overview]
Message-ID: <8f789f96-e3e1-41a1-b566-75f92a78fd26@virtuozzo.com> (raw)
In-Reply-To: <20260916143816.1712971-3-den@openvz.org>


1. Minor: the ordering claim belongs in code, and in patch 1. "Nothing
takes the two in the other order" checks out: the walk callbacks in
cpr-exec only do madvise and mprotect, and the ramblock vmstate has no
callbacks. But the order was already forced by patch 1, so fold the
statement into the lock comment there.

  2. Nit: ram_block_add() does find, then save or delete, in three
separate acquisitions. It is correct only because the ramlist mutex is
held across all three at system/physmem.c:1913-2058. A one-line comment
saying the ramlist mutex is the real serializer there would save the
next reader the same analysis.

On 9/16/26 5:38 PM, Denis V. Lunev wrote:
> From: Denis V. Lunev <den@openvz.org>
> 
> The ramblock entries live in the same registry as the descriptors and
> are reached the same way, from RAM block setup and teardown, so they
> need the same protection.
> 
> Take the lock in their accessors too. qemu_ram_free() already holds the
> ramlist mutex when it calls in here, and nothing takes the two in the
> other order.
> 
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> ---
>  migration/cpr.c | 26 +++++++++++++++++++++-----
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/migration/cpr.c b/migration/cpr.c
> index 78cf430e386..5c0d2c142aa 100644
> --- a/migration/cpr.c
> +++ b/migration/cpr.c
> @@ -244,8 +244,13 @@ static CprRamBlock *find_ramblock(CprRamBlockList *head, const char *name)
>  
>  void cpr_save_ramblock(const char *name, cpr_ramblock_t ram)
>  {
> -    CprRamBlock *elem = find_ramblock(&cpr_state.ramblocks, name);
> -    cpr_ramblock_t old_ram = elem ? elem->ram : (cpr_ramblock_t) {0, 0};
> +    CprRamBlock *elem;
> +    cpr_ramblock_t old_ram;
> +
> +    QEMU_LOCK_GUARD(&cpr_state_lock);
> +
> +    elem = find_ramblock(&cpr_state.ramblocks, name);
> +    old_ram = elem ? elem->ram : (cpr_ramblock_t) {0, 0};
>  
>      if (old_ram.addr == 0) {
>          do_cpr_save_ramblock(name, ram);
> @@ -260,7 +265,11 @@ void cpr_save_ramblock(const char *name, cpr_ramblock_t ram)
>  
>  void cpr_delete_ramblock(const char *name)
>  {
> -    CprRamBlock *elem = find_ramblock(&cpr_state.ramblocks, name);
> +    CprRamBlock *elem;
> +
> +    QEMU_LOCK_GUARD(&cpr_state_lock);
> +
> +    elem = find_ramblock(&cpr_state.ramblocks, name);
>  
>      if (elem) {
>          QLIST_REMOVE(elem, next);
> @@ -273,8 +282,13 @@ void cpr_delete_ramblock(const char *name)
>  
>  cpr_ramblock_t cpr_find_ramblock(const char *name)
>  {
> -    CprRamBlock *elem = find_ramblock(&cpr_state.ramblocks, name);
> -    cpr_ramblock_t ram = elem ? elem->ram : (cpr_ramblock_t) {0, 0};
> +    CprRamBlock *elem;
> +    cpr_ramblock_t ram;
> +
> +    QEMU_LOCK_GUARD(&cpr_state_lock);
> +
> +    elem = find_ramblock(&cpr_state.ramblocks, name);
> +    ram = elem ? elem->ram : (cpr_ramblock_t) {0, 0};
>  
>      trace_cpr_find_ramblock(name, (void *) ram.addr, ram.length);
>      return ram;
> @@ -284,6 +298,8 @@ bool cpr_walk_ramblock(cpr_walk_ramblock_cb cb)
>  {
>      CprRamBlock *elem;
>  
> +    QEMU_LOCK_GUARD(&cpr_state_lock);
> +
>      QLIST_FOREACH(elem, &cpr_state.ramblocks, next) {
>          g_assert(elem->ram.addr && elem->ram.length);
>          if (!cb(elem->ram, elem->name)) {


      reply	other threads:[~2026-09-16 17:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 14:38 [PATCH hci-8.0 0/2] migration/cpr: lock the cpr state #VSTOR-145529 Denis V. Lunev
2026-09-16 14:38 ` [PATCH hci-8.0 1/2] migration/cpr: lock the saved fds #VSTOR-145529 Denis V. Lunev
2026-09-16 17:18   ` Andrey Drobyshev
2026-09-16 14:38 ` [PATCH hci-8.0 2/2] migration/cpr: lock the ramblocks #VSTOR-145529 Denis V. Lunev
2026-09-16 17:18   ` Andrey Drobyshev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f789f96-e3e1-41a1-b566-75f92a78fd26@virtuozzo.com \
    --to=andrey.drobyshev@virtuozzo.com \
    --cc=den@openvz.org \
    --cc=svt-core@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.