[Qemu-commits] [qemu/qemu] bba237: softmmu/physmem: fix memory leak in dirty_memory_e...

[Wh1sper]

  Branch: refs/heads/staging-8.2
  Home:   https://github.com/qemu/qemu
  Commit: bba2372cb821926ae0ff40602999438b38e25871
      
https://github.com/qemu/qemu/commit/bba2372cb821926ae0ff40602999438b38e25871
  Author: David Hildenbrand <david@redhat.com>
  Date:   2024-09-12 (Thu, 12 Sep 2024)

  Changed paths:
    M include/exec/ramlist.h
    M system/physmem.c

  Log Message:
  -----------
  softmmu/physmem: fix memory leak in dirty_memory_extend()

As reported by Peter, we might be leaking memory when removing the
highest RAMBlock (in the weird ram_addr_t space), and adding a new one.

We will fail to realize that we already allocated bitmaps for more
dirty memory blocks, and effectively discard the pointers to them.

Fix it by getting rid of last_ram_page() and by remembering the number
of dirty memory blocks that have been allocated already.

While at it, let's use "unsigned int" for the number of blocks, which
should be sufficient until we reach ~32 exabytes.

Looks like this leak was introduced as we switched from using a single
bitmap_zero_extend() to allocating multiple bitmaps:
bitmap_zero_extend() relies on g_renew() which should have taken care of
this.

Resolves: 
https://lkml.kernel.org/r/CAFEAcA-k7a+VObGAfCFNygQNfCKL=AfX6A4kScq=VSSK0peqPg@mail.gmail.com
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Fixes: 5b82b703b69a ("memory: RCU ram_list.dirty_memory[] for safe RAM hotplug")
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-stable@nongnu.org
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20240828090743.128647-1-david@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit b84f06c2bee727b3870b4eeccbe3a45c5aea14c1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix due to lack of
 v9.0.0-rc4-49-g15f7a80c49cb "RAMBlock: Add support of KVM private guest memfd")


  Commit: 387d044a8000776af43bc085bb095f8fad194153
      
https://github.com/qemu/qemu/commit/387d044a8000776af43bc085bb095f8fad194153
  Author: Tiago Pasqualini <tiago.pasqualini@canonical.com>
  Date:   2024-09-12 (Thu, 12 Sep 2024)

  Changed paths:
    M crypto/pbkdf.c

  Log Message:
  -----------
  crypto: run qcrypto_pbkdf2_count_iters in a new thread

CPU time accounting in the kernel has been demonstrated to have a
sawtooth pattern[1][2]. This can cause the getrusage system call to
not be as accurate as we are expecting, which can cause this calculation
to stall.

The kernel discussions shows that this inaccuracy happens when CPU time
gets big enough, so this patch changes qcrypto_pbkdf2_count_iters to run
in a fresh thread to avoid this inaccuracy. It also adds a sanity check
to fail the process if CPU time is not accounted.

[1] 
https://lore.kernel.org/lkml/159231011694.16989.16351419333851309713.tip-bot2@tip-bot2/
[2] 
https://lore.kernel.org/lkml/20221226031010.4079885-1-maxing.lan@bytedance.com/t/#m1c7f2fdc0ea742776a70fd1aa2a2e414c437f534

Resolves: #2398
Signed-off-by: Tiago Pasqualini <tiago.pasqualini@canonical.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit c72cab5ad9f849bbcfcf4be7952b8b8946cc626e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: fff9274a6d3d19c01fbcb05d65e26312a36a42ec
      
https://github.com/qemu/qemu/commit/fff9274a6d3d19c01fbcb05d65e26312a36a42ec
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2024-09-12 (Thu, 12 Sep 2024)

  Changed paths:
    M crypto/pbkdf-gcrypt.c
    M crypto/pbkdf-gnutls.c

  Log Message:
  -----------
  crypto: check gnutls & gcrypt support the requested pbkdf hash

Both gnutls and gcrypt can be configured to exclude support for certain
algorithms via a runtime check against system crypto policies. Thus it
is not sufficient to have a compile time test for hash support in their
pbkdf implementations.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit e6c09ea4f9e5f8af92a6453642b84b9efd52892f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 97edd78e33e09178e78d7980c028b5165280f094
      
https://github.com/qemu/qemu/commit/97edd78e33e09178e78d7980c028b5165280f094
  Author: Haoran Zhang <wh1sper@zju.edu.cn>
  Date:   2024-09-12 (Thu, 12 Sep 2024)

  Changed paths:
    M hw/display/vhost-user-gpu.c

  Log Message:
  -----------
  hw/display/vhost-user-gpu.c: fix vhost_user_gpu_chr_read()

fix vhost_user_gpu_chr_read() where `size` was incorrectly passed to 
`msg->flags`.

Fixes: 267f664658 ("hw/display: add vhost-user-vga & gpu-pci")
Signed-off-by: Haoran Zhang <wh1sper@zju.edu.cn>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit d6192f3f7593536a4285e8ab6c6cf3f34973ce62)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


Compare: https://github.com/qemu/qemu/compare/40fbd80abe03...97edd78e33e0

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications