[Qemu-commits] [qemu/qemu] 28bb0a: io: fix QIONetListener memory leak

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 28bb0a59f84c11c42117a7009646508256ed4475
      
https://github.com/qemu/qemu/commit/28bb0a59f84c11c42117a7009646508256ed4475
  Author: Paolo Bonzini <address@hidden>
  Date:   2018-02-15 (Thu, 15 Feb 2018)

  Changed paths:
    M io/net-listener.c

  Log Message:
  -----------
  io: fix QIONetListener memory leak

The sources array does not escape out of qio_net_listener_wait_client, so
we have to free it.

Reported by Coverity.

Signed-off-by: Paolo Bonzini <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>


  Commit: a46ded1de5cf0edd6c780e071ddafb92601070b5
      
https://github.com/qemu/qemu/commit/a46ded1de5cf0edd6c780e071ddafb92601070b5
  Author: Edgar Kaziakhmedov <address@hidden>
  Date:   2018-02-15 (Thu, 15 Feb 2018)

  Changed paths:
    M io/channel-websock.c

  Log Message:
  -----------
  io/channel-websock: handle continuous reads without any data

According to the current implementation of websocket protocol in QEMU,
qio_channel_websock_handshake_io tries to read handshake from the
channel to start communication over socket. But this approach
doesn't cover scenario when socket was closed while handshaking.
Therefore, if G_IO_IN is caught and qio_channel_read returns zero,
error has to be set and connection has to be done.

Such behaviour causes 100% CPU load in main QEMU loop, because main loop
poll continues to receive and handle G_IO_IN events from websocket.

Step to reproduce 100% CPU load:
1) start qemu with the simplest configuration
$ qemu -vnc [::1]:1,websocket=7500
2) open any vnc listener (which doesn't follow websocket
protocol)
$ vncviewer :7500
3) kill listener
4) qemu main thread eats 100% CPU

Signed-off-by: Edgar Kaziakhmedov <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>


  Commit: 902f6e14fc68743ce24efb7d87dc3f8464a78bf3
      
https://github.com/qemu/qemu/commit/902f6e14fc68743ce24efb7d87dc3f8464a78bf3
  Author: Ross Lagerwall <address@hidden>
  Date:   2018-02-15 (Thu, 15 Feb 2018)

  Changed paths:
    M include/io/channel-file.h
    M io/channel-file.c
    M tests/test-io-channel-file.c

  Log Message:
  -----------
  io: Fix QIOChannelFile when creating and opening read-write

The code wrongly passes the mode to open() only if O_WRONLY is set.
Instead, the mode should be passed when O_CREAT is set (or O_TMPFILE on
Linux). Fix this by always passing the mode since open() will correctly
ignore the mode if it is not needed. Add a testcase which exercises this
bug and also change the existing testcase to check that the mode of the
created file is correct.

Signed-off-by: Ross Lagerwall <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>


  Commit: a2565df12c59362c061084a0c853dace410cac26
      
https://github.com/qemu/qemu/commit/a2565df12c59362c061084a0c853dace410cac26
  Author: Ross Lagerwall <address@hidden>
  Date:   2018-02-15 (Thu, 15 Feb 2018)

  Changed paths:
    M io/channel-file.c

  Log Message:
  -----------
  io: Don't call close multiple times in QIOChannelFile

If the file descriptor underlying QIOChannelFile is closed in the
io_close() method, don't close it again in the finalize() method since
the file descriptor number may have been reused in the meantime.

Signed-off-by: Ross Lagerwall <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>


  Commit: b8f244b13ca3c754c34c0ab1c2b0e7241b54318a
      
https://github.com/qemu/qemu/commit/b8f244b13ca3c754c34c0ab1c2b0e7241b54318a
  Author: Ross Lagerwall <address@hidden>
  Date:   2018-02-15 (Thu, 15 Feb 2018)

  Changed paths:
    M io/channel-file.c

  Log Message:
  -----------
  io: Add /dev/fdset/ support to QIOChannelFile

Add /dev/fdset/ support to QIOChannelFile by calling qemu_open() instead
of open() and qemu_close() instead of close(). There is a subtle
semantic change since qemu_open() automatically sets O_CLOEXEC, but this
doesn't affect any of the users of the function.

Signed-off-by: Ross Lagerwall <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>


  Commit: fe823b6f87b2ebedd692ca480ceb9693439d816e
      
https://github.com/qemu/qemu/commit/fe823b6f87b2ebedd692ca480ceb9693439d816e
  Author: Thomas Huth <address@hidden>
  Date:   2018-02-15 (Thu, 15 Feb 2018)

  Changed paths:
    M io/channel-command.c

  Log Message:
  -----------
  io/channel-command: Do not kill the child process after closing the pipe

We are currently facing some migration failure on s390x when running
certain avocado-vt tests, e.g. when running the test
type_specific.io-github-autotest-qemu.migrate.with_reboot.exec.gzip_exec.
This test is using 'migrate -d "exec:nc localhost 5200"' for the migration.
The problem is detected at the receiving side, where the migration stream
apparently ends too early. However, the cause for the problem is at the
sending side: After writing the migration stream into the pipe to netcat,
the source QEMU calls qio_channel_command_close() which closes the pipe
and immediately (!) kills the child process afterwards (via the function
qio_channel_command_abort()). So if the  sending netcat did not read the
final bytes from the pipe yet, or  if it did not manage to send out all
its buffers yet, it is killed before the whole migration stream is passed
to the destination side.

QEMU can not know how much time is required by the child process to send
over all migration data, so we should not kill it, neither directly nor
after a delay. Let's simply wait for the child process to exit gracefully
instead (this was also the behaviour of pclose() that was used in "exec:"
migration before the QIOChannel rework).

Signed-off-by: Thomas Huth <address@hidden>
Signed-off-by: Daniel P. Berrangé <address@hidden>


  Commit: 6809df1df036840d41a0cc9ca77cc6a0214fb1b5
      
https://github.com/qemu/qemu/commit/6809df1df036840d41a0cc9ca77cc6a0214fb1b5
  Author: Jan Beulich <address@hidden>
  Date:   2018-02-15 (Thu, 15 Feb 2018)

  Changed paths:
    M Makefile

  Log Message:
  -----------
  allow to build with older sed

sed's -E option may not be supported by older distros. As there's no
point using sed here at all, use just shell mechanisms to establish the
variable values, starting from the stem instead of the full target.

Signed-off-by: Jan Beulich <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>


  Commit: 0402ca3c70356e09e694fece39256790ff7755f2
      
https://github.com/qemu/qemu/commit/0402ca3c70356e09e694fece39256790ff7755f2
  Author: Peter Maydell <address@hidden>
  Date:   2018-02-16 (Fri, 16 Feb 2018)

  Changed paths:
    M Makefile
    M include/io/channel-file.h
    M io/channel-command.c
    M io/channel-file.c
    M io/channel-websock.c
    M io/net-listener.c
    M tests/test-io-channel-file.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/berrange/tags/qio-next-pull-request' 
into staging

# gpg: Signature made Thu 15 Feb 2018 17:50:22 GMT
# gpg:                using RSA key BE86EBB415104FDF
# gpg: Good signature from "Daniel P. Berrange <address@hidden>"
# gpg:                 aka "Daniel P. Berrange <address@hidden>"
# Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF

* remotes/berrange/tags/qio-next-pull-request:
  allow to build with older sed
  io/channel-command: Do not kill the child process after closing the pipe
  io: Add /dev/fdset/ support to QIOChannelFile
  io: Don't call close multiple times in QIOChannelFile
  io: Fix QIOChannelFile when creating and opening read-write
  io/channel-websock: handle continuous reads without any data
  io: fix QIONetListener memory leak

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/5e5432b766c4...0402ca3c7035