qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 3b59ee: migration/rdma: fix potential nullptr


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 3b59ee: migration/rdma: fix potential nullptr access in rd...
Date: Tue, 02 Jun 2020 02:30:31 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 3b59ee722726d023f4a56d711aef362ab9ba777e
      
https://github.com/qemu/qemu/commit/3b59ee722726d023f4a56d711aef362ab9ba777e
  Author: Pan Nengyuan <pannengyuan@huawei.com>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M migration/rdma.c

  Log Message:
  -----------
  migration/rdma: fix potential nullptr access in rdma_start_incoming_migration

'rdma' is NULL when taking the first error branch in 
rdma_start_incoming_migration.
And it will cause a null pointer access in label 'err'. Fix that.

Fixes: 59c59c67ee6b0327ae932deb303caa47919aeb1e
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200508100755.7875-2-pannengyuan@huawei.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
  Note this is CID 1428762


  Commit: 2f0c285aaac5fdc4c5c2f8e03fa8c11e679c50c4
      
https://github.com/qemu/qemu/commit/2f0c285aaac5fdc4c5c2f8e03fa8c11e679c50c4
  Author: Pan Nengyuan <pannengyuan@huawei.com>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M migration/rdma.c

  Log Message:
  -----------
  migration/rdma: cleanup rdma context before g_free to avoid memleaks

When error happen in initializing 'rdma_return_path', we should cleanup rdma 
context
before g_free(rdma) to avoid some memleaks. This patch fix that.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200508100755.7875-3-pannengyuan@huawei.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 89cf4fe34f4afa671a2ab5d9430021ea12106274
      
https://github.com/qemu/qemu/commit/89cf4fe34f4afa671a2ab5d9430021ea12106274
  Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M hmp-commands.hx
    M include/monitor/hmp.h
    M qom/qom-hmp-cmds.c
    M tests/qtest/test-hmp.c

  Log Message:
  -----------
  hmp: Implement qom-get HMP command

This started off as Andreas Färber's implementation from
March 2015, but after feedback from Paolo and Markus it morphed into
using the json output which handles structs reasonably.

Use with qom-list to find the members of an object.

(qemu) qom-get /backend/console[0]/device/vga.rom[0] size
65536
(qemu) qom-get /machine smm
"auto"
(qemu) qom-get /machine rtc-time
{
    "tm_year": 120,
    "tm_sec": 51,
    "tm_hour": 9,
    "tm_min": 50,
    "tm_mon": 4,
    "tm_mday": 20
}
(qemu) qom-get /machine frob
Error: Property '.frob' not found

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20200520151108.160598-2-dgilbert@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 7d2ef6dcc1cf87e7506487051eda010b479f5d0e
      
https://github.com/qemu/qemu/commit/7d2ef6dcc1cf87e7506487051eda010b479f5d0e
  Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M hmp-commands.hx
    M qom/qom-hmp-cmds.c

  Log Message:
  -----------
  hmp: Simplify qom-set

Simplify qom_set by making it use qmp_qom_set and the JSON parser.

(qemu) qom-get /machine smm
"auto"
(qemu) qom-set /machine smm "auto"

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20200520151108.160598-3-dgilbert@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
  With 's'->'S' type change suggested by Paolo and Markus


  Commit: 93bb3d8d4cdadf90f714b8ab71b4caa16092f38c
      
https://github.com/qemu/qemu/commit/93bb3d8d4cdadf90f714b8ab71b4caa16092f38c
  Author: Miklos Szeredi <mszeredi@redhat.com>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M tools/virtiofsd/passthrough_ll.c

  Log Message:
  -----------
  virtiofsd: remove symlink fallbacks

Path lookup in the kernel has special rules for looking up magic symlinks
under /proc.  If a filesystem operation is instructed to follow symlinks
(e.g. via AT_SYMLINK_FOLLOW or lack of AT_SYMLINK_NOFOLLOW), and the final
component is such a proc symlink, then the target of the magic symlink is
used for the operation, even if the target itself is a symlink.  I.e. path
lookup is always terminated after following a final magic symlink.

I was erronously assuming that in the above case the target symlink would
also be followed, and so workarounds were added for a couple of operations
to handle the symlink case.  Since the symlink can be handled simply by
following the proc symlink, these workardouds are not needed.

Also remove the "norace" option, which disabled the workarounds.

Commit bdfd66788349 ("virtiofsd: Fix xattr operations") already dealt with
the same issue for xattr operations.

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Message-Id: <20200514140736.20561-1-mszeredi@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: e0d138aa9b3a4c72fe8bca735686132fdea646b7
      
https://github.com/qemu/qemu/commit/e0d138aa9b3a4c72fe8bca735686132fdea646b7
  Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M include/migration/vmstate.h

  Log Message:
  -----------
  migration/vmstate: Remove unnecessary MemoryRegion forward declaration

"migration/vmstate.h" only uses pointer to MemoryRegion, which
is already forward declared in "qemu/typedefs.h".

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200530165512.15225-1-f4bug@amsat.org>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: bb70b66ed7a5600a63437fb6d64dedb44f670e58
      
https://github.com/qemu/qemu/commit/bb70b66ed7a5600a63437fb6d64dedb44f670e58
  Author: Lukas Straub <lukasstraub2@web.de>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M migration/colo.c
    M migration/migration.h

  Log Message:
  -----------
  migration/colo.c: Use event instead of semaphore

If multiple packets miscompare in a short timeframe, the semaphore
value will be increased multiple times. This causes multiple
checkpoints even if one would be sufficient.

Fix this by using a event instead of a semaphore for triggering
checkpoints. Now, checkpoint requests will be ignored until the
checkpoint event is sent to colo-compare (which releases the
miscompared packets).

Benchmark results (iperf3):
Client-to-server tcp:
without patch: ~66 Mbit/s
with patch: ~61 Mbit/s
Server-to-client tcp:
without patch: ~702 Kbit/s
with patch: ~16 Mbit/s

Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Message-Id: 
<fd601ba1beb524aada54ba66e87ebfc12cf4574b.1589193382.git.lukasstraub2@web.de>
Reviewed-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 786d8b8e38b134f99556e08047e016563b7063f9
      
https://github.com/qemu/qemu/commit/786d8b8e38b134f99556e08047e016563b7063f9
  Author: Lukas Straub <lukasstraub2@web.de>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M migration/colo.c

  Log Message:
  -----------
  migration/colo.c: Use cpu_synchronize_all_states()

cpu_synchronize_all_pre_loadvm() marks all vcpus as dirty, so the
registers are loaded from CPUState before we continue running
the vm. However if we failover during checkpoint, CPUState is not
initialized and the registers are loaded with garbage. This causes
guest hangs and crashes.

Fix this by using cpu_synchronize_all_states(), which initializes
CPUState from the current cpu registers additionally to marking
the vcpus as dirty.

Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Message-Id: 
<9675031ce557b73ebd10e7bd20ebbf57f30b177c.1589193382.git.lukasstraub2@web.de>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 24fa16f8cc374935458672b027829180ea4b4460
      
https://github.com/qemu/qemu/commit/24fa16f8cc374935458672b027829180ea4b4460
  Author: Lukas Straub <lukasstraub2@web.de>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M migration/colo.c
    M migration/ram.c
    M migration/ram.h

  Log Message:
  -----------
  migration/colo.c: Flush ram cache only after receiving device state

If we suceed in receiving ram state, but fail receiving the device
state, there will be a mismatch between the two.

Fix this by flushing the ram cache only after the vmstate has been
received.

Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Message-Id: 
<3289d007d494cb0e2f05b1cf4ae6a78d300fede3.1589193382.git.lukasstraub2@web.de>
Reviewed-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 92c932de6c4a2b25826201e9d0740207136953c6
      
https://github.com/qemu/qemu/commit/92c932de6c4a2b25826201e9d0740207136953c6
  Author: Lukas Straub <lukasstraub2@web.de>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M migration/colo.c

  Log Message:
  -----------
  migration/colo.c: Relaunch failover even if there was an error

If vmstate_loading is true, secondary_vm_do_failover will set failover
status to FAILOVER_STATUS_RELAUNCH and return success without initiating
failover. However, if there is an error during the vmstate_loading
section, failover isn't relaunched. Instead we then wait for
failover on colo_incoming_sem.

Fix this by relaunching failover even if there was an error. Also,
to make this work properly, set vmstate_loading to false when
returning during the vmstate_loading section.

Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Message-Id: 
<f60b0a8e2fadaaec792e04819dfc46951842d6ba.1589193382.git.lukasstraub2@web.de>
Reviewed-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 4fa8ed25b8dc996d92c60fb6b63752593be5f3a4
      
https://github.com/qemu/qemu/commit/4fa8ed25b8dc996d92c60fb6b63752593be5f3a4
  Author: Lukas Straub <lukasstraub2@web.de>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M migration/colo.c

  Log Message:
  -----------
  migration/colo.c: Move colo_notify_compares_event to the right place

If the secondary has to failover during checkpointing, it still is
in the old state (i.e. different state than primary). Thus we can't
expose the primary state until after the checkpoint is sent.

This fixes sporadic connection reset of client connections during
failover.

Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Message-Id: 
<d4555dd5146a54518c4d9d4efd996b7c745c6687.1589193382.git.lukasstraub2@web.de>
Reviewed-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 773861274ad75a62c7ecf70ecc8e4ba31ed62190
      
https://github.com/qemu/qemu/commit/773861274ad75a62c7ecf70ecc8e4ba31ed62190
  Author: Lukas Straub <lukasstraub2@web.de>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M migration/migration.c

  Log Message:
  -----------
  migration/migration.c: Fix hang in ram_save_host_page

migration_rate_limit will erroneously ratelimit a shutdown socket,
which causes the migration thread to hang in ram_save_host_page
if the socket is shutdown.

Fix this by explicitly testing if the socket has errors or was
shutdown in migration_rate_limit.

Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Message-Id: 
<e79085bbe2d46dfa007dd41820194d5e2d4fcd80.1590007004.git.lukasstraub2@web.de>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 853a60b87024b2f5d7c0c54a432d7798cb679900
      
https://github.com/qemu/qemu/commit/853a60b87024b2f5d7c0c54a432d7798cb679900
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2020-06-01 (Mon, 01 Jun 2020)

  Changed paths:
    M hmp-commands.hx
    M include/migration/vmstate.h
    M include/monitor/hmp.h
    M migration/colo.c
    M migration/migration.c
    M migration/migration.h
    M migration/ram.c
    M migration/ram.h
    M migration/rdma.c
    M qom/qom-hmp-cmds.c
    M tests/qtest/test-hmp.c
    M tools/virtiofsd/passthrough_ll.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/dgilbert/tags/pull-migration-20200601a' 
into staging

Migration/virtio/hmp pull 2020-06-01

A mixed pull with:
  - RDMA migration fix (CID 1428762)
  - HMP qom-get addition and qom-set cleanup
  - a virtiofsd fix
  - COLO fixes

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

# gpg: Signature made Mon 01 Jun 2020 19:37:15 BST
# gpg:                using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7
# gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" 
[full]
# Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A  9FA9 0516 331E BC5B FDE7

* remotes/dgilbert/tags/pull-migration-20200601a:
  migration/migration.c: Fix hang in ram_save_host_page
  migration/colo.c: Move colo_notify_compares_event to the right place
  migration/colo.c: Relaunch failover even if there was an error
  migration/colo.c: Flush ram cache only after receiving device state
  migration/colo.c: Use cpu_synchronize_all_states()
  migration/colo.c: Use event instead of semaphore
  migration/vmstate: Remove unnecessary MemoryRegion forward declaration
  virtiofsd: remove symlink fallbacks
  hmp: Simplify qom-set
  hmp: Implement qom-get HMP command
  migration/rdma: cleanup rdma context before g_free to avoid memleaks
  migration/rdma: fix potential nullptr access in rdma_start_incoming_migration

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/6bb228190ef0...853a60b87024



reply via email to

[Prev in Thread] Current Thread [Next in Thread]