[Qemu-commits] [qemu/qemu] d5f2af: 9pfs: don't try to flush self and avoid QEMU hang ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: d5f2af7b95b738b25272a98319b09540a0606d14
      
https://github.com/qemu/qemu/commit/d5f2af7b95b738b25272a98319b09540a0606d14
  Author: Greg Kurz <address@hidden>
  Date:   2017-03-21 (Tue, 21 Mar 2017)

  Changed paths:
    M hw/9pfs/9p.c

  Log Message:
  -----------
  9pfs: don't try to flush self and avoid QEMU hang on reset

According to the 9P spec [*], when a client wants to cancel a pending I/O
request identified by a given tag (uint16), it must send a Tflush message
and wait for the server to respond with a Rflush message before reusing this
tag for another I/O. The server may still send a completion message for the
I/O if it wasn't actually cancelled but the Rflush message must arrive after
that.

QEMU hence waits for the flushed PDU to complete before sending the Rflush
message back to the client.

If a client sends 'Tflush tag oldtag' and tag == oldtag, QEMU will then
allocate a PDU identified by tag, find it in the PDU list and wait for
this same PDU to complete... i.e. wait for a completion that will never
happen. This causes a tag and ring slot leak in the guest, and a PDU
leak in QEMU, all of them limited by the maximal number of PDUs (128).
But, worse, this causes QEMU to hang on device reset since v9fs_reset()
wants to drain all pending I/O.

This insane behavior is likely to denote a bug in the client, and it would
deserve an Rerror message to be sent back. Unfortunately, the protocol
allows it and requires all flush requests to suceed (only a Tflush response
is expected).

The only option is to detect when we have to handle a self-referencing
flush request and report success to the client right away.

[*] http://man.cat-v.org/plan_9/5/flush

Reported-by: Al Viro <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>


  Commit: 262169abe74b4c2d8b299b7499904cfc3c1902ea
      
https://github.com/qemu/qemu/commit/262169abe74b4c2d8b299b7499904cfc3c1902ea
  Author: Greg Kurz <address@hidden>
  Date:   2017-03-21 (Tue, 21 Mar 2017)

  Changed paths:
    M hw/9pfs/9p-proxy.c

  Log Message:
  -----------
  9pfs: proxy: assert if unmarshal fails

Replies from the virtfs proxy are made up of a fixed-size header (8 bytes)
and a payload of variable size (maximum 64kb). When receiving a reply,
the proxy backend first reads the whole header and then unmarshals it.
If the header is okay, it then does the same operation with the payload.

Since the proxy backend uses a pre-allocated buffer which has enough room
for a header and the maximum payload size, marshalling should never fail
with fixed size arguments. Any error here is likely to result from a more
serious corruption in QEMU and we'd better dump core right away.

This patch adds error checks where they are missing and converts the
associated error paths into assertions.

This should also address Coverity's complaints CID 1348519 and CID 1348520,
about not always checking the return value of proxy_unmarshal().

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: 41a56822e3049a83e05ebd1b0d7d040cb09a52fb
      
https://github.com/qemu/qemu/commit/41a56822e3049a83e05ebd1b0d7d040cb09a52fb
  Author: Peter Maydell <address@hidden>
  Date:   2017-03-21 (Tue, 21 Mar 2017)

  Changed paths:
    M hw/9pfs/9p-proxy.c
    M hw/9pfs/9p.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging

This pull request fixes a potential QEMU hang in 9pfs and two issues
reported by Coverity.

# gpg: Signature made Tue 21 Mar 2017 09:57:58 GMT
# gpg:                using DSA key 0x02FC3AEB0101DBC2
# gpg: Good signature from "Greg Kurz <address@hidden>"
# gpg:                 aka "Greg Kurz <address@hidden>"
# gpg:                 aka "Greg Kurz <address@hidden>"
# gpg:                 aka "Gregory Kurz (Groug) <address@hidden>"
# gpg:                 aka "[jpeg image of size 3330]"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 2BD4 3B44 535E C0A7 9894  DBA2 02FC 3AEB 0101 DBC2

* remotes/gkurz/tags/for-upstream:
  9pfs: proxy: assert if unmarshal fails
  9pfs: don't try to flush self and avoid QEMU hang on reset

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


Compare: https://github.com/qemu/qemu/compare/cc720a5dc4d0...41a56822e304