aboutsummaryrefslogtreecommitdiff
path: root/hw/9pfs/9p.c
AgeCommit message (Collapse)Author
2017-06-299pfs: handle transport errors in pdu_complete()Greg Kurz
Contrary to what is written in the comment, a buggy guest can misconfigure the transport buffers and pdu_marshal() may return an error. If this ever happens, it is up to the transport layer to handle the situation (9P is transport agnostic). This fixes Coverity issue CID1348518. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-06-29virtio-9p: break device if buffers are misconfiguredGreg Kurz
The 9P protocol is transport agnostic: if the guest misconfigured the buffers, the best we can do is to set the broken flag on the device. Signed-off-by: Greg Kurz <groug@kaod.org>
2017-06-299pfs: local: Add support for custom fmode/dmode in 9ps mapped security modesTobias Schramm
In mapped security modes, files are created with very restrictive permissions (600 for files and 700 for directories). This makes file sharing between virtual machines and users on the host rather complicated. Imagine eg. a group of users that need to access data produced by processes on a virtual machine. Giving those users access to the data will be difficult since the group access mode is always 0. This patch makes the default mode for both files and directories configurable. Existing setups that don't know about the new parameters keep using the current secure behavior. Signed-off-by: Tobias Schramm <tobleminer@gmail.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-05-259pfs: check return value of v9fs_co_name_to_path()Greg Kurz
These v9fs_co_name_to_path() call sites have always been around. I guess no care was taken to check the return value because the name_to_path operation could never fail at the time. This is no longer true: the handle and synth backends can already fail this operation, and so will the local backend soon. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-05-259pfs: drop pdu_push_and_notify()Greg Kurz
Only pdu_complete() needs to notify the client that a request has completed. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-05-25virtio-9p/xen-9p: move 9p specific bits to core 9p codeGreg Kurz
These bits aren't related to the transport so let's move them to the core code. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-05-17migration: Create migration/blocker.hJuan Quintela
This allows us to remove lots of includes of migration/migration.h Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-04-049pfs: clear migration blocker at session resetGreg Kurz
The migration blocker survives a device reset: if the guest mounts a 9p share and then gets rebooted with system_reset, it will be unmigratable until it remounts and umounts the 9p share again. This happens because the migration blocker is supposed to be cleared when we put the last reference on the root fid, but virtfs_reset() wrongly calls free_fid() instead of put_fid(). This patch fixes virtfs_reset() so that it honor the way fids are supposed to be manipulated: first get a reference and later put it back when you're done. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Li Qiang <liqiang6-s@360.cn>
2017-04-049pfs: fix multiple flush for same requestGreg Kurz
If a client tries to flush the same outstanding request several times, only the first flush completes. Subsequent ones keep waiting for the request completion in v9fs_flush() and, therefore, leak a PDU. This will cause QEMU to hang when draining active PDUs the next time the device is reset. Let have each flush request wake up the next one if any. The last waiter frees the cancelled PDU. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-03-279pfs: fix file descriptor leakLi Qiang
The v9fs_create() and v9fs_lcreate() functions are used to create a file on the backend and to associate it to a fid. The fid shouldn't be already in-use, otherwise both functions may silently leak a file descriptor or allocated memory. The current code doesn't check that. This patch ensures that the fid isn't already associated to anything before using it. Signed-off-by: Li Qiang <liqiang6-s@360.cn> (reworded the changelog, Greg Kurz) Signed-off-by: Greg Kurz <groug@kaod.org>
2017-03-219pfs: don't try to flush self and avoid QEMU hang on resetGreg Kurz
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 <viro@ZenIV.linux.org.uk> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-02-28fsdev: add IO throttle support to fsdev devicesPradeep Jagadeesh
This patchset adds the throttle support for the 9p-local driver. For now this functionality can be enabled only through qemu cli options. QMP interface and support to other drivers need further extensions. To make it simple for other 9p drivers, the throttle code has been put in separate files. Signed-off-by: Pradeep Jagadeesh <pradeep.jagadeesh@huawei.com> Reviewed-by: Alberto Garcia <berto@igalia.com> (pass extra NULL CoMutex * argument to qemu_co_queue_wait(), added options to qemu-options.hx, Greg Kurz) Signed-off-by: Greg Kurz <groug@kaod.org>
2017-02-289pfs: fix v9fs_lock error casePaolo Bonzini
In this case, we are marshaling an error status instead of the errno value. Reorganize the out and out_nofid labels to look like all the other cases. Coverity reports this because the "err = -ENOENT" and "err = -EINVAL" assignments above are dead, overwritten by the call to pdu_marshal. (Coverity issues CID1348512 and CID1348513) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (also open-coded the success path since locking is a nop for us, Greg Kurz) Signed-off-by: Greg Kurz <groug@kaod.org>
2017-02-21coroutine-lock: add mutex argument to CoQueue APIsPaolo Bonzini
All that CoQueue needs in order to become thread-safe is help from an external mutex. Add this to the API. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20170213181244.16297-6-pbonzini@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-25Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into stagingPeter Maydell
This pull request fixes a 2.9 regression and a long standing bug that can cause 9p clients to hang. Other patches are minor enhancements. # gpg: Signature made Wed 25 Jan 2017 10:12:27 GMT # gpg: using DSA key 0x02FC3AEB0101DBC2 # gpg: Good signature from "Greg Kurz <groug@kaod.org>" # gpg: aka "Greg Kurz <groug@free.fr>" # gpg: aka "Greg Kurz <gkurz@fr.ibm.com>" # gpg: aka "Greg Kurz <gkurz@linux.vnet.ibm.com>" # gpg: aka "Gregory Kurz (Groug) <groug@free.fr>" # gpg: aka "Gregory Kurz (Cimai Technology) <gkurz@cimai.com>" # gpg: aka "Gregory Kurz (Meiosys Technology) <gkurz@meiosys.com>" # 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: fix offset error in v9fs_xattr_read() 9pfs: local: trivial cosmetic fix in pwritev op 9pfs: fix off-by-one error in PDU free list tests: virtio-9p: improve error reporting 9pfs: add missing coroutine_fn annotations Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-01-259pfs: fix offset error in v9fs_xattr_read()Greg Kurz
The current code tries to copy `read_count' bytes starting at offset `offset' from a `read_count`-sized iovec. This causes v9fs_pack() to fail with ENOBUFS. Since the PDU iovec is already partially filled with `offset' bytes, let's skip them when creating `qiov_full' and have v9fs_pack() to copy the whole of it. Moreover, this is consistent with the other places where v9fs_init_qiov_from_pdu() is called. This fixes commit "bcb8998fac16 9pfs: call v9fs_init_qiov_from_pdu before v9fs_pack". Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-01-259pfs: fix off-by-one error in PDU free listGreg Kurz
The server can handle MAX_REQ - 1 PDUs at a time and the virtio-9p device has a MAX_REQ sized virtqueue. If the client manages to fill up the virtqueue, pdu_alloc() will fail and the request won't be processed without any notice to the client (it actually causes the linux 9p client to hang). This has been there since the beginning (commit 9f10751365b2 "virtio-9p: Add a virtio 9p device to qemu"), but it needs an agressive workload to run in the guest to show up. We actually allocate MAX_REQ PDUs and I see no reason not to link them all into the free list, so let's fix the init loop. Reported-by: Tuomas Tynkkynen <tuomas@tuxera.com> Suggested-by: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-01-259pfs: add missing coroutine_fn annotationsGreg Kurz
Signed-off-by: Greg Kurz <groug@kaod.org>
2017-01-24migration: disallow migrate_add_blocker during migrationAshijeet Acharya
If a migration is already in progress and somebody attempts to add a migration blocker, this should rightly fail. Add an errp parameter and a retcode return value to migrate_add_blocker. Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Ashijeet Acharya <ashijeetacharya@gmail.com> Message-Id: <1484566314-3987-5-git-send-email-ashijeetacharya@gmail.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Acked-by: Greg Kurz <groug@kaod.org> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Merged with recent 'Allow invtsc migration' change
2017-01-039pfs: fix crash when fsdev is missingGreg Kurz
If the user passes -device virtio-9p without the corresponding -fsdev, QEMU dereferences a NULL pointer and crashes. This is a 2.8 regression introduced by commit 702dbcc274e2c. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Li Qiang <liq3ea@gmail.com>
2017-01-039pfs: introduce init_out/in_iov_from_pduStefano Stabellini
Not all 9pfs transports share memory between request and response. For those who don't, it is necessary to know how much memory is required in the response. Split the existing init_iov_from_pdu function in two: init_out_iov_from_pdu (for writes) and init_in_iov_from_pdu (for reads). init_in_iov_from_pdu takes an additional size parameter to specify the memory required for the response message. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-01-039pfs: call v9fs_init_qiov_from_pdu before v9fs_packStefano Stabellini
v9fs_xattr_read should not access VirtQueueElement elems directly. Move v9fs_init_qiov_from_pdu up in the file and call v9fs_init_qiov_from_pdu before v9fs_pack. Use v9fs_pack on the new iovec. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-01-039pfs: introduce transport specific callbacksStefano Stabellini
Don't call virtio functions from 9pfs generic code, use generic function callbacks instead. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-01-039pfs: move pdus to V9fsStateStefano Stabellini
pdus are initialized and used in 9pfs common code. Move the array from V9fsVirtioState to V9fsState. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2016-11-239pfs: add cleanup operation in FileOperationsLi Qiang
Currently, the backend of VirtFS doesn't have a cleanup function. This will lead resource leak issues if the backed driver allocates resources. This patch addresses this issue. Signed-off-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2016-11-239pfs: adjust the order of resource cleanup in device unrealizeLi Qiang
Unrealize should undo things that were set during realize in reverse order. So should do in the error path in realize. Signed-off-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2016-11-019pfs: drop excessive error message from virtfs_reset()Greg Kurz
The virtfs_reset() function is called either when the virtio-9p device gets reset, or when the client starts a new 9P session. In both cases, if it finds fids from a previous session, the following is printed in the monitor: 9pfs:virtfs_reset: One or more uncluncked fids found during reset For example, if a linux guest with a mounted 9P share is reset from the monitor with system_reset, the message will be printed. This is excessive since these fids are now clunked and the state is clean. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-11-019pfs: don't BUG_ON() if fid is already openedGreg Kurz
A buggy or malicious guest could pass the id of an already opened fid and cause QEMU to abort. Let's return EINVAL to the guest instead. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-11-019pfs: xattrcreate requires non-opened fidsGreg Kurz
The xattrcreate operation only makes sense on a freshly cloned fid actually, since any open state would be leaked because of the fid_type change. This is indeed what the linux kernel client does: fid = clone_fid(fid); [...] retval = p9_client_xattrcreate(fid, name, value_len, flags); This patch also reverts commit ff55e94d23ae since we are sure that a fid with type P9_FID_NONE doesn't have a previously allocated xattr. Signed-off-by: Greg Kurz <groug@kaod.org>
2016-11-019pfs: limit xattr size in xattrcreateGreg Kurz
We shouldn't allow guests to create extended attribute with arbitrary sizes. On linux hosts, the limit is XATTR_SIZE_MAX. Let's use it. Signed-off-by: Greg Kurz <groug@kaod.org>
2016-11-019pfs: fix integer overflow issue in xattr read/writeLi Qiang
The v9fs_xattr_read() and v9fs_xattr_write() are passed a guest originated offset: they must ensure this offset does not go beyond the size of the extended attribute that was set in v9fs_xattrcreate(). Unfortunately, the current code implement these checks with unsafe calculations on 32 and 64 bit values, which may allow a malicious guest to cause OOB access anyway. Fix this by comparing the offset and the xattr size, which are both uint64_t, before trying to compute the effective number of bytes to read or write. Suggested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Li Qiang <liqiang6-s@360.cn> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-By: Guido Günther <agx@sigxcpu.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2016-11-019pfs: add xattrwalk_fid field in V9fsXattr structLi Qiang
Currently, 9pfs sets the 'copied_len' field in V9fsXattr to -1 to tag xattr walk fid. As the 'copied_len' is also used to account for copied bytes, this may make confusion. This patch add a bool 'xattrwalk_fid' to tag the xattr walk fid. Suggested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Li Qiang <liqiang6-s@360.cn> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2016-10-179pfs: fix memory leak in v9fs_writeLi Qiang
If an error occurs when marshalling the transfer length to the guest, the v9fs_write() function doesn't free an IO vector, thus leading to a memory leak. This patch fixes the issue. Signed-off-by: Li Qiang <liqiang6-s@360.cn> Reviewed-by: Greg Kurz <groug@kaod.org> [groug, rephrased the changelog] Signed-off-by: Greg Kurz <groug@kaod.org>
2016-10-179pfs: fix memory leak in v9fs_linkLi Qiang
The v9fs_link() function keeps a reference on the source fid object. This causes a memory leak since the reference never goes down to 0. This patch fixes the issue. Signed-off-by: Li Qiang <liqiang6-s@360.cn> Reviewed-by: Greg Kurz <groug@kaod.org> [groug, rephrased the changelog] Signed-off-by: Greg Kurz <groug@kaod.org>
2016-10-179pfs: fix memory leak in v9fs_xattrcreateLi Qiang
The 'fs.xattr.value' field in V9fsFidState object doesn't consider the situation that this field has been allocated previously. Every time, it will be allocated directly. This leads to a host memory leak issue if the client sends another Txattrcreate message with the same fid number before the fid from the previous time got clunked. Signed-off-by: Li Qiang <liqiang6-s@360.cn> Reviewed-by: Greg Kurz <groug@kaod.org> [groug, updated the changelog to indicate how the leak can occur] Signed-off-by: Greg Kurz <groug@kaod.org>
2016-10-179pfs: fix information leak in xattr readLi Qiang
9pfs uses g_malloc() to allocate the xattr memory space, if the guest reads this memory before writing to it, this will leak host heap memory to the guest. This patch avoid this. Signed-off-by: Li Qiang <liqiang6-s@360.cn> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2016-10-17virtio-9p: add reset handlerGreg Kurz
Virtio devices should implement the VirtIODevice->reset() function to perform necessary cleanup actions and to bring the device to a quiescent state. In the case of the virtio-9p device, this means: - emptying the list of active PDUs (i.e. draining all in-flight I/O) - freeing all fids (i.e. close open file descriptors and free memory) That's what this patch does. The reset handler first waits for all active PDUs to complete. Since completion happens in the QEMU global aio context, we just have to loop around aio_poll() until the active list is empty. The freeing part involves some actions to be performed on the backend, like closing file descriptors or flushing extended attributes to the underlying filesystem. The virtfs_reset() function already does the job: it calls free_fid() for all open fids not involved in an ongoing I/O operation. We are sure this is the case since we have drained the PDU active list. The current code implements all backend accesses with coroutines, but we want to stay synchronous on the reset path. We can either change the current code to be able to run when not in coroutine context, or create a coroutine context and wait for virtfs_reset() to complete. This patch goes for the latter because it results in simpler code. Note that we also need to create a dummy PDU because it is also an API to pass the FsContext pointer to all backend callbacks. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-179pfs: only free completed request if not flushedGreg Kurz
If a PDU has a flush request pending, the current code calls pdu_free() twice: 1) pdu_complete()->pdu_free() with pdu->cancelled set, which does nothing 2) v9fs_flush()->pdu_free() with pdu->cancelled cleared, which moves the PDU back to the free list. This works but it complexifies the logic of pdu_free(). With this patch, pdu_complete() only calls pdu_free() if no flush request is pending, i.e. qemu_co_queue_next() returns false. Since pdu_free() is now supposed to be called with pdu->cancelled cleared, the check in pdu_free() is dropped and replaced by an assertion. Signed-off-by: Greg Kurz <groug@kaod.org>
2016-10-179pfs: drop useless check in pdu_free()Greg Kurz
Out of the three users of pdu_free(), none ever passes a NULL pointer to this function. Signed-off-by: Greg Kurz <groug@kaod.org>
2016-10-179pfs: use coroutine_fn annotation in hw/9pfs/9p.[ch]Greg Kurz
All these functions either call the v9fs_co_* functions which have the coroutine_fn annotation, or pdu_complete() which calls qemu_co_queue_next(). Let's mark them to make it obvious they execute in coroutine context. Signed-off-by: Greg Kurz <groug@kaod.org>
2016-10-179pfs: fix potential host memory leak in v9fs_readLi Qiang
In 9pfs read dispatch function, it doesn't free two QEMUIOVector object thus causing potential memory leak. This patch avoid this. Signed-off-by: Li Qiang <liqiang6-s@360.cn> Signed-off-by: Greg Kurz <groug@kaod.org>
2016-10-179pfs: allocate space for guest originated empty stringsLi Qiang
If a guest sends an empty string paramater to any 9P operation, the current code unmarshals it into a V9fsString equal to { .size = 0, .data = NULL }. This is unfortunate because it can cause NULL pointer dereference to happen at various locations in the 9pfs code. And we don't want to check str->data everywhere we pass it to strcmp() or any other function which expects a dereferenceable pointer. This patch enforces the allocation of genuine C empty strings instead, so callers don't have to bother. Out of all v9fs_iov_vunmarshal() users, only v9fs_xattrwalk() checks if the returned string is empty. It now uses v9fs_string_size() since name.data cannot be NULL anymore. Signed-off-by: Li Qiang <liqiang6-s@360.cn> [groug, rewritten title and changelog, fix empty string check in v9fs_xattrwalk()] Signed-off-by: Greg Kurz <groug@kaod.org>
2016-09-199pfs: fix potential segfault during walkGreg Kurz
If the call to fid_to_qid() returns an error, we will call v9fs_path_free() on uninitialized paths. It is a regression introduced by the following commit: 56f101ecce0e 9pfs: handle walk of ".." in the root directory Let's fix this by initializing dpath and path before calling fid_to_qid(). Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> [groug: updated the changelog to indicate this is regression and to provide the offending commit SHA1] Signed-off-by: Greg Kurz <groug@kaod.org>
2016-09-169pfs: introduce v9fs_path_sprintf() helperGreg Kurz
This helper is similar to v9fs_string_sprintf(), but it includes the terminating NUL character in the size field. This is to avoid doing v9fs_string_sprintf((V9fsString *) &path) and then bumping the size. Affected users are changed to use this new helper. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2016-09-169pfs: drop useless v9fs_string_null() functionGreg Kurz
The v9fs_string_null() function just calls v9fs_string_free(). Also it only has 4 users, whereas v9fs_string_free() has 87. This patch converts users to call directly v9fs_string_free() and drops the useless function. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2016-08-309pfs: handle walk of ".." in the root directoryGreg Kurz
The 9P spec at http://man.cat-v.org/plan_9/5/intro says: All directories must support walks to the directory .. (dot-dot) meaning parent directory, although by convention directories contain no explicit entry for .. or . (dot). The parent of the root directory of a server's tree is itself. This means that a client cannot walk further than the root directory exported by the server. In other words, if the client wants to walk "/.." or "/foo/../..", the server should answer like the request was to walk "/". This patch just does that: - we cache the QID of the root directory at attach time - during the walk we compare the QID of each path component with the root QID to detect if we're in a "/.." situation - if so, we skip the current component and go to the next one Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-309pfs: forbid . and .. in file namesGreg Kurz
According to the 9P spec http://man.cat-v.org/plan_9/5/open about the create request: The names . and .. are special; it is illegal to create files with these names. This patch causes the create and lcreate requests to fail with EINVAL if the file name is either "." or "..". Even if it isn't explicitly written in the spec, this patch extends the checking to all requests that may cause a directory entry to be created: - mknod - rename - renameat - mkdir - link - symlink The unlinkat request also gets patched for consistency (even if rmdir("foo/..") is expected to fail according to POSIX.1-2001). The various error values come from the linux manual pages. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-309pfs: forbid illegal path namesGreg Kurz
Empty path components don't make sense for most commands and may cause undefined behavior, depending on the backend. Also, the walk request described in the 9P spec [1] clearly shows that the client is supposed to send individual path components: the official linux client never sends portions of path containing the / character for example. Moreover, the 9P spec [2] also states that a system can decide to restrict the set of supported characters used in path components, with an explicit mention "to remove slashes from name components". This patch introduces a new name_is_illegal() helper that checks the names sent by the client are not empty and don't contain unwanted chars. Since 9pfs is only supported on linux hosts, only the / character is checked at the moment. When support for other hosts (AKA. win32) is added, other chars may need to be blacklisted as well. If a client sends an illegal path component, the request will fail and ENOENT is returned to the client. [1] http://man.cat-v.org/plan_9/5/walk [2] http://man.cat-v.org/plan_9/5/intro Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-07-13coroutine: move entry argument to qemu_coroutine_createPaolo Bonzini
In practice the entry argument is always known at creation time, and it is confusing that sometimes qemu_coroutine_enter is used with a non-NULL argument to re-enter a coroutine (this happens in block/sheepdog.c and tests/test-coroutine.c). So pass the opaque value at creation time, for consistency with e.g. aio_bh_new. Mostly done with the following semantic patch: @ entry1 @ expression entry, arg, co; @@ - co = qemu_coroutine_create(entry); + co = qemu_coroutine_create(entry, arg); ... - qemu_coroutine_enter(co, arg); + qemu_coroutine_enter(co); @ entry2 @ expression entry, arg; identifier co; @@ - Coroutine *co = qemu_coroutine_create(entry); + Coroutine *co = qemu_coroutine_create(entry, arg); ... - qemu_coroutine_enter(co, arg); + qemu_coroutine_enter(co); @ entry3 @ expression entry, arg; @@ - qemu_coroutine_enter(qemu_coroutine_create(entry), arg); + qemu_coroutine_enter(qemu_coroutine_create(entry, arg)); @ reentry @ expression co; @@ - qemu_coroutine_enter(co, NULL); + qemu_coroutine_enter(co); except for the aforementioned few places where the semantic patch stumbled (as expected) and for test_co_queue, which would otherwise produce an uninitialized variable warning. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-06-069p: switch back to readdir()Greg Kurz
This patch changes the 9p code to use readdir() again instead of readdir_r(), which is deprecated in glibc 2.24. All the locking was put in place by a previous patch. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-02 05:07:19 +0000