[Qemu-commits] [qemu/qemu] 2e2293: tests/virtio-9p: add terminating null in v9fs_stri...

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 2e2293c238d4daa791ab7ff60b326a322892df3a
      
https://github.com/qemu/qemu/commit/2e2293c238d4daa791ab7ff60b326a322892df3a
  Author: Christian Schoenebeck <address@hidden>
  Date:   2020-02-08 (Sat, 08 Feb 2020)

  Changed paths:
    M tests/qtest/virtio-9p-test.c

  Log Message:
  -----------
  tests/virtio-9p: add terminating null in v9fs_string_read()

The 9p protocol sends strings in general without null termination
over the wire. However for future use of this functions it is
beneficial for the delivered string to be null terminated though
for being able to use the string with standard C functions which
often rely on strings being null terminated.

Signed-off-by: Christian Schoenebeck <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>


  Commit: e16453a31a00c1c0a199cab0617e8aa888f6419a
      
https://github.com/qemu/qemu/commit/e16453a31a00c1c0a199cab0617e8aa888f6419a
  Author: Christian Schoenebeck <address@hidden>
  Date:   2020-02-08 (Sat, 08 Feb 2020)

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

  Log Message:
  -----------
  9pfs: require msize >= 4096

A client establishes a session by sending a Tversion request along with a
'msize' parameter which client uses to suggest server a maximum message
size ever to be used for communication (for both requests and replies)
between client and server during that session. If client suggests a 'msize'
smaller than 4096 then deny session by server immediately with an error
response (Rlerror for "9P2000.L" clients or Rerror for "9P2000.u" clients)
instead of replying with Rversion.

So far any msize submitted by client with Tversion was simply accepted by
server without any check. Introduction of some minimum msize makes sense,
because e.g. a msize < 7 would not allow any subsequent 9p operation at
all, because 7 is the size of the header section common by all 9p message
types.

A substantial higher value of 4096 was chosen though to prevent potential
issues with some message types. E.g. Rreadlink may yield up to a size of
PATH_MAX which is usually 4096, and like almost all 9p message types,
Rreadlink is not allowed to be truncated by the 9p protocol. This chosen
size also prevents a similar issue with Rreaddir responses (provided client
always sends adequate 'count' parameter with Treaddir), because even though
directory entries retrieval may be split up over several T/Rreaddir
messages; a Rreaddir response must not truncate individual directory entries
though. So msize should be large enough to return at least one directory
entry with the longest possible file name supported by host. Most file
systems support a max. file name length of 255. Largest known file name
lenght limit would be currently ReiserFS with max. 4032 bytes, which is
also covered by this min. msize value because 4032 + 35 < 4096.

Furthermore 4096 is already the minimum msize of the Linux kernel's 9pfs
client.

Signed-off-by: Christian Schoenebeck <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>


  Commit: d36a5c227099f3f74da27a730350b012b6e99cdd
      
https://github.com/qemu/qemu/commit/d36a5c227099f3f74da27a730350b012b6e99cdd
  Author: Christian Schoenebeck <address@hidden>
  Date:   2020-02-08 (Sat, 08 Feb 2020)

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

  Log Message:
  -----------
  9pfs: validate count sent by client with T_readdir

A good 9p client sends T_readdir with "count" parameter that's sufficiently
smaller than client's initially negotiated msize (maximum message size).
We perform a check for that though to avoid the server to be interrupted
with a "Failed to encode VirtFS reply type 41" transport error message by
bad clients. This count value constraint uses msize - 11, because 11 is the
header size of R_readdir.

Signed-off-by: Christian Schoenebeck <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
[groug: added comment ]
Signed-off-by: Greg Kurz <address@hidden>


  Commit: af46a3b233787323417bbca7b1aa3290935a5bdf
      
https://github.com/qemu/qemu/commit/af46a3b233787323417bbca7b1aa3290935a5bdf
  Author: Christian Schoenebeck <address@hidden>
  Date:   2020-02-08 (Sat, 08 Feb 2020)

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

  Log Message:
  -----------
  hw/9pfs/9p-synth: added directory for readdir test

This will provide the following virtual files by the 9pfs
synth driver:

  - /ReadDirDir/ReadDirFile99
  - /ReadDirDir/ReadDirFile98
  ...
  - /ReadDirDir/ReadDirFile1
  - /ReadDirDir/ReadDirFile0

This virtual directory and its virtual 100 files will be
used by the upcoming 9pfs readdir tests.

Signed-off-by: Christian Schoenebeck <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>


  Commit: 4829469fd9ff091bc99176512b194b468ed60c1f
      
https://github.com/qemu/qemu/commit/4829469fd9ff091bc99176512b194b468ed60c1f
  Author: Christian Schoenebeck <address@hidden>
  Date:   2020-02-08 (Sat, 08 Feb 2020)

  Changed paths:
    M tests/qtest/virtio-9p-test.c

  Log Message:
  -----------
  tests/virtio-9p: added readdir test

The first readdir test simply checks the amount of directory
entries returned by 9pfs server, according to the created amount
of virtual files on 9pfs synth driver side. Then the subsequent
readdir test also checks whether all directory entries have the
expected file names (as created on 9pfs synth driver side),
ignoring their precise order in result list though.

Signed-off-by: Christian Schoenebeck <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>


  Commit: 2822602cbe2be98229b882101dfdb9d3a738c611
      
https://github.com/qemu/qemu/commit/2822602cbe2be98229b882101dfdb9d3a738c611
  Author: Christian Schoenebeck <address@hidden>
  Date:   2020-02-08 (Sat, 08 Feb 2020)

  Changed paths:
    M MAINTAINERS

  Log Message:
  -----------
  MAINTAINERS: 9pfs: Add myself as reviewer

Currently 9pfs is only taken care of by Greg. Since I am actively working
on 9pfs and already became quite used to the code base, it makes sense to
volunteer as reviewer for 9pfs related patches.

Signed-off-by: Christian Schoenebeck <address@hidden>
Cc: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>


  Commit: 2b8a51cdb3e8d15a5c35de7a2e76a813ae7358f0
      
https://github.com/qemu/qemu/commit/2b8a51cdb3e8d15a5c35de7a2e76a813ae7358f0
  Author: Peter Maydell <address@hidden>
  Date:   2020-02-10 (Mon, 10 Feb 2020)

  Changed paths:
    M MAINTAINERS
    M hw/9pfs/9p-synth.c
    M hw/9pfs/9p-synth.h
    M hw/9pfs/9p.c
    M hw/9pfs/9p.h
    M tests/qtest/virtio-9p-test.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-02-08' into 
staging

9p patches:
- some more protocol sanity checks
- qtest for readdir
- Christian Schoenebeck now official reviewer

# gpg: Signature made Sat 08 Feb 2020 08:38:10 GMT
# gpg:                using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6
# gpg: Good signature from "Greg Kurz <address@hidden>" [full]
# gpg:                 aka "Gregory Kurz <address@hidden>" [full]
# gpg:                 aka "[jpeg image of size 3330]" [full]
# Primary key fingerprint: B482 8BAF 9431 40CE F2A3  4910 71D4 D5E5 822F 73D6

* remotes/gkurz/tags/9p-next-2020-02-08:
  MAINTAINERS: 9pfs: Add myself as reviewer
  tests/virtio-9p: added readdir test
  hw/9pfs/9p-synth: added directory for readdir test
  9pfs: validate count sent by client with T_readdir
  9pfs: require msize >= 4096
  tests/virtio-9p: add terminating null in v9fs_string_read()

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


Compare: https://github.com/qemu/qemu/compare/73d336510cf1...2b8a51cdb3e8