9pfs: differentiate readdir lock between 9P2000.u vs. 9P2000.L
commitd2c5cf7ca15490b4737a5393e51abf0301b98971
authorChristian Schoenebeck <qemu_oss@crudebyte.com>
Wed, 29 Jul 2020 08:39:12 +0000 (29 10:39 +0200)
committerChristian Schoenebeck <qemu_oss@crudebyte.com>
Wed, 12 Aug 2020 07:17:32 +0000 (12 09:17 +0200)
tree52f86dfd831fc9606c18c0ced3f3f2305437ecc5
parent0c4356ba7dafc8ecb5877a42fc0d68d45ccf5951
9pfs: differentiate readdir lock between 9P2000.u vs. 9P2000.L

Previous patch suggests that it might make sense to use a different mutex
type now while handling readdir requests, depending on the precise
protocol variant, as v9fs_do_readdir_with_stat() (used by 9P2000.u) uses
a CoMutex to avoid deadlocks that might happen with QemuMutex otherwise,
whereas do_readdir_many() (used by 9P2000.L) should better use a
QemuMutex, as the precise behaviour of a failed CoMutex lock on fs driver
side would not be clear.

And to avoid the wrong lock type being used, be now strict and error out
if a 9P2000.L client sends a Tread on a directory, and likeweise error out
if a 9P2000.u client sends a Treaddir request.

This patch is just intended as transitional measure, as currently 9P2000.u
vs. 9P2000.L implementations currently differ where the main logic of
fetching directory entries is located at (9P2000.u still being more top
half focused, while 9P2000.L already being bottom half focused in regards
to fetching directory entries that is).

Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <9a2ddc347e533b0d801866afd9dfac853d2d4106.1596012787.git.qemu_oss@crudebyte.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
hw/9pfs/9p.c
hw/9pfs/9p.h