| Message ID | c81e7219e0736f80bfd3553676a19e2992cff41d.1732820037.git.qemu_oss@crudebyte.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [PULL,for-9.2,1/7] 9pfs: cleanup V9fsFidState | expand |
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index 851e36b9a1..578517739a 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -1596,7 +1596,13 @@ static void coroutine_fn v9fs_getattr(void *opaque) retval = -ENOENT; goto out_nofid; } - retval = v9fs_co_lstat(pdu, &fidp->path, &stbuf); + if ((fidp->fid_type == P9_FID_FILE && fidp->fs.fd != -1) || + (fidp->fid_type == P9_FID_DIR && fidp->fs.dir.stream)) + { + retval = v9fs_co_fstat(pdu, fidp, &stbuf); + } else { + retval = v9fs_co_lstat(pdu, &fidp->path, &stbuf); + } if (retval < 0) { goto out; }
With a valid file ID (FID) of an open file, it should be possible to send a 'Tgettattr' 9p request and successfully receive a 'Rgetattr' response, even if the file has been removed in the meantime. Currently this would fail with ENOENT. I.e. this fixes the following misbehaviour with a 9p Linux client: open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 unlink("/home/tst/filename") = 0 fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory) Expected results: open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 unlink("/home/tst/filename") = 0 fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 This is because 9p server is always using a path name based lstat() call which fails as soon as the file got removed. So to fix this, use fstat() whenever we have an open file descriptor already. Fixes: 00ede4c2529b ("virtio-9p: getattr server implementation...") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/103 Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <4c41ad47f449a5cc8bfa9285743e029080d5f324.1732465720.git.qemu_oss@crudebyte.com> --- hw/9pfs/9p.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)